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

select delete_flag,delete_timefrom 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這一步的詳細(xì)信息可以看出：

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

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

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

select delete_flag,delete_timefrom D_OrderInfo    WHERE OrderId = 'xxxx'

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

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

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

sendStringParametersAsUnicode=false

后記：

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

此外，JDBC 驅(qū)動程序提供了 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