最近監(jiān)控到類似這樣一個慢查詢：

select delete_flag,delete_time
from D_OrderInfo 
   WHERE ( OrderId is not null and
          OrderId = N'xxxx') 

D_OrderInfo表上有一個OrderId的索引，但OrderId字段是Varchar類型。

由于開發(fā)框架MyBatis自動生成Where條件不會指定參數(shù)類型，字符串類型的參數(shù)到了SQLServer里就自動成了NVARCHAR(4000)類型了，坑人的是，不指定參數(shù)類型也就罷了，還自動加了個OrderId Is NOT NULL這樣一個非SARG的條件，執(zhí)行計劃成了這樣：

---------------------------------------------------------------------------------------------
如果沒有OrderId IS NOT NULL這個條件，執(zhí)行計劃會是這樣的：

由于參數(shù)類型Nvarchar比索引字段類型varchar優(yōu)先級要高，不能直接轉(zhuǎn)換，但SQLServer優(yōu)化器最終還是將他轉(zhuǎn)成了一個范圍值，最終的等號查詢也變成了類似一個小范圍查詢。

可以從Index Seek這一步的詳細信息可以看出：

------------------------------------------------------------------------

如果參數(shù)類型匹配，那么執(zhí)行計劃會是想象中的那樣（雖然沒有包含到,還是有Key Lookup）：

當(dāng)然，有點小小強迫癥的我最終希望的寫法是這樣的：

select delete_flag,delete_time
from D_OrderInfo 
   WHERE OrderId = 'xxxx'

執(zhí)行計劃當(dāng)然也會是這樣的：

只是，只是不知道最終開發(fā)大神能改成什么樣......

開發(fā)大神的解決方案：連接字符串中配置：

sendStringParametersAsUnicode=false

后記：

默認情況下，Java 中的字符數(shù)據(jù)作為 Unicode 進行處理；Java String 對象表示 Unicode 字符數(shù)據(jù)。在 JDBC 驅(qū)動程序中，唯一可以不遵守此規(guī)則的是 ASCII 流 getter 和 setter 方法，這屬于比較特殊的情況，因為這些方法使用的字節(jié)流帶有單個已知代碼頁 (ASCII) 的隱式假定。

此外，JDBC 驅(qū)動程序提供了 sendStringParametersAsUnicode 連接字符串屬性。此屬性可用于指定作為 ASCII 而不是 Unicode 來發(fā)送的字符數(shù)據(jù)的預(yù)定義參數(shù)。

作為性能方面的一項增強功能，可以通過設(shè)置 sendStringParametersAsUnicode 連接字符串屬性將 String 參數(shù)以非 Unicode 格式傳遞到 SQL Server。sendStringParametersAsUnicode 的默認設(shè)置為“true”，這意味著 String 參數(shù)將作為 Unicode 進行發(fā)送。

如果 sendStringParametersAsUnicode 設(shè)置為“false”，則連接上的所有 String 參數(shù)將使用數(shù)據(jù)庫默認的排序規(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

最新評論