设为首页 收藏本站
查看: 1181|回复: 0

[经验分享] SQL Server 执行计划利用统计信息对数据行的预估原理二(为什么复合索引列顺序会影响到执行计划对数据行的预估)

[复制链接]

尚未签到

发表于 2017-7-13 19:37:22 | 显示全部楼层 |阅读模式
  本文出处:http://www.cnblogs.com/wy123/p/6008477.html
  关于统计信息对数据行数做预估,之前写过对非相关列(单独或者单独的索引列)进行预估时候的算法,参考这里。
  今天来写一下统计信息对于复合索引在预估时候的计算方法和潜在问题。
  本文原形来自于是个实际业务问题,某SQL在利用一个符合索引做查询的时候,发现始终会出现预估误差较大的情况,
  而改变复合索引的列顺序,这个预估行数的误差会发生变化,
  也就是说,Create  index idx_index1 ON TableName(col1,col2)与Create index idx_index2 on TableName(col2,col1)
  用完全一样的的查询条件做查询,两个索引的执行计划对其预估的行数是不一样的
  究其原因在哪里呢?
  先造一个测试环境:



CREATE TABLE TestStatistics
(
COL1 INT IDENTITY(1,1)  ,
COL2 INT                ,
COL3 DATETIME           ,
COL4 VARCHAR(50)            
)
GO
INSERT INTO TestStatistics VALUES (RAND()*10,CAST(GETDATE()-RAND()*300 AS date),NEWID())
GO 1000000
  问题重现
  首先看一个非常有意思的问题,
在同一张表上,
先这么建一个索引:CREATE INDEX IDX_COL2_COL3 ON TestStatistics(COL2,COL3)
执行一个查询,预估为4127.86行
然后DROP掉上面的索引,继续创建一个索引:CREATE INDEX IDX_COL3_COL2 ON TestStatistics(COL3,COL2)
注意COL2和COL3的顺序不一致
继续执行上面的查询(查询条件不变,数据不变,仅仅是索引列顺序发生了变化),这一次预估为2414.91行
  查询条件一样,数据也一样,为什么改变复合索引列顺序会影响到执行计划对数据行的预估呢?
DSC0000.png DSC0001.png

  首先来看第一个索引时候的预估算法:
  这个查询他预估为4127.86行,如下图

  说起来预估,就离不开统计信息,首先来看IDX_COL2_COL3这个索引的统计信息,
  我们知道,对于复合索引,统计信息中只有前导列的统计数据,也就是说IDX_COL3_COL2这个索引只有COL2这个列的统计信息,如下截图
  对于COL2=2的统计信息,统计为100336行,我们记住这个数字
DSC0002.png

  统计信息的另外一个特点就是在会在查询列(非索引列)上自动创建统计信息,如下截图
  查询执行过程中,自动创建了一个名字为:_WA_Sys_00000003_24E8431A的统计信息
  这个统计信息就是对COL3列的统计,可以发现在大于等于2012-10-20之后的统计行数
DSC0003.png

  
  在SQL Server 2012中,对数据行的预估计算方式是各个字段的选择性的乘积,
  假如Pn代表不同字段的密度,那么预估行数的计算方法就是: 预估行数=p0*p1*p2*p3……*RowCount
  可以利用这个算法,计算目前数据下,预估出来的结果:4217.86,跟执行计划预估是一致的,非常完美!
DSC0004.png DSC0005.png

  当删除了IDX_COL2_COL3重建建立顺序为COL3+COL2的索引的时候,预估如下
  与上面同样的查询条件,预估为2414.91行

  依据上面的分析步骤,首先来分析索引列上的统计信息,如下截图为大于等于2016-10-20之后的预估行数
DSC0006.png

  同理,本次查询也会自动建立COL2列上的统计信息(IDX_COL2_COL3索引被删除),观察这个统计信息对COL2=2的预估为83711.36行
DSC0007.png

  同样我们利用上述公式,来计算预估的行数:2414.9035行,也非常完美地吻合和执行计划预估的结果
DSC0008.png DSC0009.png

  至此,应该很清楚一开始的问题了,就是为什么复合索引列顺序不一致,在查询的时候导致预估也不一致的原因。
  最根本的原因有就是:
  符合索引上只有前导列的统计信息,查询引擎会根据需要自动创建非前导列的统计信息,
  但是,非常关键一点,如果细心的话,你会发现查询引擎自动创建的统计信息的取样行数都不是100%取样的,这一点非常关键
  正是因为非前导列取样有一定的误差,导致在预估算法的时候,也即 预估行数=p0*p1*p2*p3……*RowCount的时候,密度值是不一样的
  也即在创建IDX_COL2_COL3的时候,统计出来的COL2密度为P1_1,COL3密度为P2_1,
  创建IDX_COL3_COL2的时候,统计出来的COL2密度为P1_2,COL3密度为P2_2,因为P1_1<>P1_2,P2_1<>P2_2
  因此,计算出的结果就是P1_1*P2_1<>P2_1*P2_2,原理很简单,希望看官能明白。
  照这么计算,对于两个顺序不同的统计信息,如果P1_1=P2_1并且P2_1=P2_2,那么乘积就是一样的,预估行数也就是一样的,那么是不是呢?
  
  对于不同顺序的两个索引,先看COL2,COL3顺序的索引
  在查询一次之后(建立了统计信息),执行一个百分之百取样(WITH FULLSCAN)的统计信息更新
  重新来看其预估行数,这一次预估为:2894.49
DSC00010.png

  删除COL2,COL3顺序的索引,建立COL3,COL2为顺序的索引
  在查询一次之后(建立了统计信息),执行一个百分之百取样(WITH FULLSCAN)的统计信息更新
  重新来看其预估行数,这一次预估为:同样为2894.49,是吻合上述算法
DSC00011.png

  总结:
  文本简单演示了执行计划利用统计信息预估的算法和原理,以及在计算预估行数时候可能受到的干扰因素,
  这就要求我们在建立索引的时候,不仅仅是说我建一个复合索引就完事了,也要注意其索引列的顺序对执行计划预估的影响,
  更重要的是,要注意查询引擎自动生成的统计信息对预估的影响程度。
  抛开统计信息谈索引的,都是耍流氓。抛开统计信息取样百分比谈统计信息的,也是耍流氓。
  引申出来另外一个问题:维护统计信息的时候,能只更新索引列的统计信息,忽略非索引列的统计信息吗?
  本人技术能力还很菜,写的不对的地方还请各位看官指出,谢谢。

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-393564-1-1.html 上篇帖子: [翻译]通过使用正确的search arguments来提高SQL Server数据库的性能 下篇帖子: 设置SQL server服务器的dbo架构
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表