最近監(jiān)控到類似這樣一個(gè)慢查詢：
|
1
2
3
4
|
select delete_flag,delete_timefrom D_OrderInfo WHERE ( OrderId is not null and OrderId = N'xxxx') |
D_OrderInfo表上有一個(gè)OrderId的索引，但OrderId字段是Varchar類型。
由于開發(fā)框架MyBatis自動(dòng)生成Where條件不會(huì)指定參數(shù)類型，字符串類型的參數(shù)到了SQLServer里就自動(dòng)成了NVARCHAR(4000)類型了，坑人的是，不指定參數(shù)類型也就罷了，還自動(dòng)加了個(gè)OrderId Is NOT NULL這樣一個(gè)非SARG的條件，執(zhí)行計(jì)劃成了這樣：
---------------------------------------------------------------------------------------------
如果沒有OrderId IS NOT NULL這個(gè)條件，執(zhí)行計(jì)劃會(huì)是這樣的：
由于參數(shù)類型Nvarchar比索引字段類型varchar優(yōu)先級(jí)要高，不能直接轉(zhuǎn)換，但SQLServer優(yōu)化器最終還是將他轉(zhuǎn)成了一個(gè)范圍值，最終的等號(hào)查詢也變成了類似一個(gè)小范圍查詢。
可以從Index Seek這一步的詳細(xì)信息可以看出：
------------------------------------------------------------------------
如果參數(shù)類型匹配，那么執(zhí)行計(jì)劃會(huì)是想象中的那樣（雖然沒有包含到,還是有Key Lookup）：
當(dāng)然，有點(diǎn)小小強(qiáng)迫癥的我最終希望的寫法是這樣的：
|
1
2
3
|
select delete_flag,delete_timefrom D_OrderInfo WHERE OrderId = 'xxxx' |
執(zhí)行計(jì)劃當(dāng)然也會(huì)是這樣的：
只是，只是不知道最終開發(fā)大神能改成什么樣......
開發(fā)大神的解決方案：連接字符串中配置：
|
1
|
sendStringParametersAsUnicode=false |
后記：
默認(rèn)情況下，Java 中的字符數(shù)據(jù)作為 Unicode 進(jìn)行處理；Java String 對(duì)象表示 Unicode 字符數(shù)據(jù)。在 JDBC 驅(qū)動(dòng)程序中，唯一可以不遵守此規(guī)則的是 ASCII 流 getter 和 setter 方法，這屬于比較特殊的情況，因?yàn)檫@些方法使用的字節(jié)流帶有單個(gè)已知代碼頁 (ASCII) 的隱式假定。
此外，JDBC 驅(qū)動(dòng)程序提供了 sendStringParametersAsUnicode 連接字符串屬性。此屬性可用于指定作為 ASCII 而不是 Unicode 來發(fā)送的字符數(shù)據(jù)的預(yù)定義參數(shù)。
作為性能方面的一項(xiàng)增強(qiáng)功能，可以通過設(shè)置 sendStringParametersAsUnicode 連接字符串屬性將 String 參數(shù)以非 Unicode 格式傳遞到 SQL Server。sendStringParametersAsUnicode 的默認(rèn)設(shè)置為“true”，這意味著 String 參數(shù)將作為 Unicode 進(jìn)行發(fā)送。
如果 sendStringParametersAsUnicode 設(shè)置為“false”，則連接上的所有 String 參數(shù)將使用數(shù)據(jù)庫默認(rèn)的排序規(guī)則發(fā)送到服務(wù)器。
參考：
http://d.hatena.ne.jp/gnarl/20110706/1309945379
https://technet.microsoft.com/zh-cn/library/ms378857(SQL.90).aspx
https://technet.microsoft.com/zh-cn/library/ms378988(v=sql.90).aspx
原文鏈接：http://www.cnblogs.com/ajiangg/p/5199526.html
