也谈SQL Server 2008 处理隐式数据类型转换在执行计划中的增强 (续)
2015-07-03 16:58
627 查看
在上一篇文章也谈SQL Server 2008 处理隐式数据类型转换在执行计划中的增强 中,我提到了隐式数据类型转换增加对于数据分布很不平均的表,评估的数据行数与实际值有很大出入的问题,进一步测试之后,我发现这种评估不准确性应该确实与猜测的一样,它使用了变量的评估方式。通过如下测试验证,首先建立数据分布不平均的测试表。
然后通过 varhcar和nvarchar值分别测试满足条件1条和满足条件8900条的执行计划预估行数。
得到的查询计划预估行数如下图所示
![](http://img.blog.csdn.net/20150703163939728)
从图中显示的预估数据行数可以看到,对于varchar值(不需要隐匿的数据类型转换),其预估的结果是准确的。但对于nvarchar值,不管指定的值是只有一条数据,还是有8900条数据匹配,其预估的结果都是99.0099,这说明预估并没有考虑我们指定的值。
进一步用变量测试
结果如下图所示:
![](http://img.blog.csdn.net/20150703164701028)
不管是varchar,还是nvarchar的变量,预估的行数都是99.0099,这个值与使用nvarchar常量值的结果一样,看来SQL Server查询优化器应该确实把 GetRangeThroughConvert 的结果看成变量了,这个应该是设计上考虑不太周全的地方了,毕竟指定固定常量值的时候,GetRangeThroughConvert的结果应该也是确定值才对。(这个问题在 SQL Server 2014中看起来是调整过来了,在2014中测试没有发现这样的现象)。
[code]USE tempdb GO CREATE TABLE _t( c varchar(50) ); CREATE INDEX IX_c ON _t( c ); GO -- 加入 10000 条数据 INSERT _t SELECT (9999 + id) FROM( SELECT TOP 10000 id = ROW_NUMBER() OVER( ORDER BY GETDATE() ) FROM sys.all_columns a, sys.all_columns )ID -- 将 100 - 10000 的数据变成相同值 UPDATE _t SET c = '' WHERE c >= '10100'
然后通过 varhcar和nvarchar值分别测试满足条件1条和满足条件8900条的执行计划预估行数。
[code]ALTER INDEX IX_c ON _t REBUILD; GO SET SHOWPLAN_ALL ON GO SELECT * FROM _t WHERE c = '10005'; -- 实际1条 GO SET SHOWPLAN_ALL OFF; GO ALTER INDEX IX_c ON _t REBUILD; GO SET SHOWPLAN_ALL ON GO SELECT * FROM _t WHERE c = N'10005'; -- 实际1条 GO SET SHOWPLAN_ALL OFF; GO ALTER INDEX IX_c ON _t REBUILD; GO SET SHOWPLAN_ALL ON GO SELECT * FROM _t WHERE c = ''; -- 实际9900条 GO SET SHOWPLAN_ALL OFF; GO ALTER INDEX IX_c ON _t REBUILD; GO SET SHOWPLAN_ALL ON GO SELECT * FROM _t WHERE c = N''; -- 实际9900条 GO SET SHOWPLAN_ALL OFF; GO
得到的查询计划预估行数如下图所示
从图中显示的预估数据行数可以看到,对于varchar值(不需要隐匿的数据类型转换),其预估的结果是准确的。但对于nvarchar值,不管指定的值是只有一条数据,还是有8900条数据匹配,其预估的结果都是99.0099,这说明预估并没有考虑我们指定的值。
进一步用变量测试
[code]ALTER INDEX IX_c ON _t REBUILD; GO SET SHOWPLAN_ALL ON GO DECLARE @v varchar;SELECT * FROM _t WHERE c = @v; -- varchar GO SET SHOWPLAN_ALL OFF; GO ALTER INDEX IX_c ON _t REBUILD; GO SET SHOWPLAN_ALL ON GO DECLARE @nv nvarchar;SELECT * FROM _t WHERE c = @nv; -- nvarchar GO SET SHOWPLAN_ALL OFF; GO
结果如下图所示:
不管是varchar,还是nvarchar的变量,预估的行数都是99.0099,这个值与使用nvarchar常量值的结果一样,看来SQL Server查询优化器应该确实把 GetRangeThroughConvert 的结果看成变量了,这个应该是设计上考虑不太周全的地方了,毕竟指定固定常量值的时候,GetRangeThroughConvert的结果应该也是确定值才对。(这个问题在 SQL Server 2014中看起来是调整过来了,在2014中测试没有发现这样的现象)。
相关文章推荐
- linux下导出oracle时报错【ORA-12154: TNS:could not resolve the connect identifier specified】
- MongoDB学习笔记---MapReduce
- SQL的主键和外键约束
- SQL判断一个数是整数还是小数
- JDBC读取数据库中信息统一存入哈希表中,然后进行查删增改操作
- MemCached介绍及使用例子
- Oracle SQL Developer更改DATE日期的显示格式
- RedHat Linux 安装oracle11g
- SQL用法总结
- 关于Linq to sql更新的问题
- CRITICAL keystone [-] OperationalError: (OperationalError) (2003, "Can't connect to MySQL server on
- mysql获取自增长插入行的ID
- Java中使用Jedis操作Redis
- MSSQL、MYSQL,ACCESSl,Oracle随机读取N条记录方法
- 如何使用ASP.NET Web API OData在Oracle中使用Entity Framework 6.x Code-First方式开发 OData V4 Service
- Consuming JSON Strings in SQL Server
- 《OCA认证考试指南(1Z0-061):Oracle Database 12c SQL基础》
- sql触发器
- mysql学习7备份和导出导入
- Mysql Select 语句中实现的判断