SQL Server 2008处理隐式数据类型转换在执行计划中的增强

关注我们获得更多内容

作者 | 邹建，资深数据库专家，精通各项 SQL Server 技术，具有丰富的管理、维护、优化能力以及业务应用经验。他一直热心于技术知识的分享、传播，持续活跃在 CSDN 和 MSDN 社区，曾多年蝉联 CSDN 论坛积分榜首。

此外，邹建还是 2004~2010、2013年度 MVP(微软最有价值专家) 获得者。著有《深入浅出 SQL Server 2005开发、管理与应用实例》《SQL Server 2000开发与管理应用实例》等畅销书。

在 SQL Server 查询中，不经意思的隐匿数据类型转换可能导致极大的查询性能问题，比如一个看起来没有任何问题简单的条件：WHERE c = N’x’ ，如果 c 的数据类型是 varchar，并且表中包含大量的数据，这个查询可能导致极大的性能开销，因为这个操作会导致列 c 的数据类型转换为 nvarchar与常量值匹配，在 SQL Server 2008 及之后的版本中，这种操作做了增强，一定程度上降低了性能开销，参考SQL Server 2008 处理隐式数据类型转换在执行计划中的增强 。

不过在实际应用中发现，这种增强有时候似乎没有起到作用，还是会存在很大的性能问题。 

最近找时间做了一个测试，找出了一种可能的问题。

1. 创建一个测试表

USE tempdb GOCREATE TABLE _t(    c varchar(50) );CREATE INDEX IX_c ON _t( c );GO-- 加入 10000 条数据INSERT _tSELECT (9999 + id) FROM(    SELECT TOP 10000 id = ROW_NUMBER() OVER( ORDER BY GETDATE() )    FROM sys.all_columns a, sys.all_columns )ID

2. 通过执行计划看下查询计划

-- Rebuild索引，确保无索引碎片和统计信息准确

ALTER INDEX IX_c ON _t REBUILD;GO

SET SHOWPLAN_ALL ON

GO

SELECT * FROM _t WHERE c = N'10005b';

GO

SET SHOWPLAN_ALL OFF;

注意EstimateRows列，该列值为1，表示评估的满足条件的数据是1条，现在看起来一切正常 。

3.把数据变一下，将大量数据变成相同值

-- 将 5000 条数据值变成一样，重建索引之后重新测试

UPDATE _t SET c = '15000' WHERE c >= '15000'

ALTER INDEX IX_c ON _t REBUILD;

GO

SET SHOWPLAN_ALL ON

GO

SELECT * FROM _t WHERE c = N'10005';

GO

SET SHOWPLAN_ALL OFF;

然后我们发现评估的记录数变大了 

4. 继续加大相同值的比例

-- 继续加大相同值的比例，重建索引之后重新测试

UPDATE _t SET c = '11000' WHERE c >= '11000' AND c < '15000'

ALTER INDEX IX_c ON _t REBUILD;

GO

SET SHOWPLAN_ALL ON

GO

SELECT * FROM _t WHERE c = N'10005';

GO

SET SHOWPLAN_ALL OFF;

GO

-- 继续加大相同值的比例，重建索引之后重新测试

UPDATE _t SET c = '10100' WHERE c >= '10100' AND c < '11000'

ALTER INDEX IX_c ON _t REBUILD;

GO

SET SHOWPLAN_ALL ON

GO

SELECT * FROM _t WHERE c = N'10005';

GO

SET SHOWPLAN_ALL OFF;

相应的，预估的行数也在增加 

如果我们使用正确的数据类型，WHERE c = ‘10005’，则始终可以得到正确的预估行数。 

我不确定 SQL Server是按照什么标准来预估这种情况下的记录数，从执行计划看，它将 nvarchar 值通过 GetRangeThroughConvert 评估出一个范围，实际执行的是一个范围 seek，在试验中，查询的值是一个常量，可以准确评估，难道这个转换之后，把常量当变量评估了，所以是一个泛泛的评估结果值。 

这个问题看起来不大，但在实际应用中，如果表的数据量很大，并且不是平均分布的话，这种错误的预估结果带来的性能影响是很大的，比如明明满足条件的很少，可以 seek, 但评估的结果很大，执行计划变 Scan了，在复杂的执行计划中，这个带来的影响更大。 

看起来，2008（包括R2）还没有那么省心，这种问题还得控制，特别是程序中，.Net过来的参数通常都是 nvarchar类型，这种导致性能问题的情况遇到N多了 。

最后啰嗦一下的是，在 SQL Server 2014中，没有再发现这个问题（不知道 2012中怎么样）

原创：邹建。

投稿：有投稿意向技术人请在公众号对话框留言。

转载：意向文章下方留言。

更多精彩请关注 “数据和云” 公众号 。

专业数据库服务：点击 “阅读原文” 。

招聘专栏

Oracle 售前工程师（广州、深圳、上海、武汉、北京、石家庄）

Oracle 高级工程师（上海、深圳、北京、成都、昆明、贵州、西宁）

MySQL 技术经理（上海、南京、成都）

MySQL 工程师（上海、杭州）

超高待遇：丰厚的年终奖，五险一金，高额学习基金，团建旅游，法定节假日，福利假期等。

推荐他人成功入职有好礼（iPhone X）相送 。

投递简历至邮箱：hr@enmotech.com

资源下载

关注公众号：数据和云（OraNews）回复关键字获取

2018DTCC , 数据库大会PPT

2017DTC，2017 DTC 大会 PPT

DBALIFE ，“DBA 的一天”海报

DBA04 ，DBA 手记4 电子书

122ARCH ，Oracle 12.2体系结构图

2017OOW ，Oracle OpenWorld 资料

PRELECTION ，大讲堂讲师课程资料

近期文章

仅仅使用AWR做报告? 性能优化还未入门

实战课堂：一则CPU 100%的故障分析

杨廷琨:如何编写高效SQL(含PPT)

一份高达555页的技术PPT会是什么样子？

大象起舞：用PostgreSQL解海盗分金问题

ProxySQL！像C罗一样的强大

高手过招:用SQL解决环环相扣刑侦推理问题