最近监控到类似这样一个慢查询：
|
1
2
3
4
|
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）：
当然，有点小小强迫症的我最终希望的写法是这样的：
|
1
2
3
|
select delete_flag,delete_timefrom D_OrderInfo WHERE OrderId = 'xxxx' |
执行计划当然也会是这样的：
只是，只是不知道最终开发大神能改成什么样......
开发大神的解决方案：连接字符串中配置：
|
1
|
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
原文链接：http://www.cnblogs.com/ajiangg/p/5199526.html
