关注我们获得更多内容
![640?wx_fmt=jpeg](https://i-blog.csdnimg.cn/blog_migrate/b8bb0df32dded88c24fe177f3d1ec29e.jpeg)
作者 | 邹建,资深数据库专家,精通各项 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 ,大讲堂讲师课程资料
近期文章