最近監控到類似這樣一個慢查詢：

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

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

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

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

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

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

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

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

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

select delete_flag,delete_timefrom D_OrderInfo    WHERE OrderId = 'xxxx'

執行計劃當然也會是這樣的：

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

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

sendStringParametersAsUnicode=false

后記：

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

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

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

如果 sendStringParametersAsUnicode 設置為“false”，則連接上的所有 String 參數將使用數據庫默認的排序規則發送到服務器。

參考：

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