标签：pr 偏差 PdaRecords 信息 Server WDPM 索引 SQL
SQL Server统计信息偏差影响表联结方式案例浅析
我们知道数据库中的统计信息的准确性是非常重要的。它会影响执行计划。一直想写一篇关于统计信息影响执行计划的相关博客，但是都卡在如何构造一个合适的例子上，所以一直拖着没有写。巧合，最近在生产环境中遇到这么一个案例，下面对案例中的相关信息做了脱敏处理，有些中间步骤也省略了，只关注核心部分SQL。如下所示，同事反馈一个SQL语句执行很慢。
UPDATE b
SET b.[Status] = '已扫描，未签收' ,
b.[Time] = pr.CreatedDate
FROM #Batch b
JOIN WDPM.PdaRecords pr WITH ( NOLOCK ) ON b.Batch_No = pr.OrderNo
AND pr.FunctionName = '[WDPM].[usp_SaveOutOrder]'
WHERE b.[Status] = '已打单，未扫描'
AND pr.CreatedDate > b.[Time];
如下截图所示，这个SQL语句基本上耗时271秒。一个临时表与一个表做嵌套循环连接（Nested Loops）。 因为表WDPM.PdaRecords只有一个聚集索引，所以执行计划中，这个表走聚集索引扫描。
注意：这里表WDPM.PdaRecords本身缺少合适的索引，只有一个聚集索引。后面展开讲述这个问题.这里先围绕统计信息的准确性对执行计划的影响来展开讲述。
物理表WDPM.PdaRecords的数据量为2505369（当然这个是一直在变化的。这个数值仅仅是实验前的检测记录，一直有会话对其进行DML操作，所以数据会变化，所以这里没有列出统计信息截图）。
我们看到Table Scan部分，预估行数（Estimated Number of Rows）为1， 实际行数为150。 这个偏差已经比较大了。
对于物理表WDPM.PdaRecords而言，基数估计的预估行数（Estimated Number of Rows）为921771， 但是由于嵌套循环连接，所以累加起来的实际行数（Actual Number of Rows）为： 921771*150 =138265650 。
我们知道嵌套循环（Nested Loops）算法的时间复杂度为N*M， N的预估值从1变成了150 ，这里面的偏差就大了（因为每次聚集索引扫描的开销也很大）。所以导致优化器在表的物理连接方式上选择了嵌套循环（Nested Loops), 因为预估的代价是很小的。但是实际因为统计信息的误差，导致这个代价放大了150倍。那么如果我们更新临时表的统计信息呢？然后执行这个SQL，会有什么变化呢？
如下所示，我们在执行SQL语句前，更新一下临时表的统计信息。发现优化器在获取了准确的统计信息后，在表的物理连接上选择了Hash Join方式。而且SQL语句耗时变成了1秒多。为什么呢？ 因为优化器发现选择Nested Loops的代价远远高于 Hash Join。所以它在获取了准确的信息后，作出了最优选择。之前之所以生成了一个错误的执行计划，就是因为它得到的“信息”不准确，导致它作出了错误的抉择。这个就好比你获取了错误的信息，作出了错误的选择，购买了一只错误的股票，而巴菲特由于掌握了准确的行业信息，作出了正确的选择。 购买了几只购票都大涨了。
UPDATE STATISTICS #Batch WITH FULLSCAN;
UPDATE b
SET b.[Status] = '已扫描，未签收' ,
b.[Time] = pr.CreatedDate
FROM #Batch b
JOIN WDPM.PdaRecords pr WITH ( NOLOCK ) ON b.Batch_No = pr.OrderNo
AND pr.FunctionName = '[WDPM].[usp_SaveOutOrder]'
WHERE b.[Status] = '已打单，未扫描'
AND pr.CreatedDate > b.[Time];
当然，了解到这里，还远远没有结束。我们发现表WDPM.PdaRecords 只有一个聚集索引，而且聚集索引位于Iden自增字段上，从另外一个角度来看，这个表其实是缺少合适的索引的。那么我们可以创建一个索引。
CREATE INDEX IX_PdaRecords_N1 ON wdpm.PdaRecords(OrderNo,FunctionName)
创建索引后，即使不更新临时表#Batch的统计信息，我们发现执行计划也会走嵌套循环（Nested Loops)，而不会走Hash Join了。这个又是什么原因呢？
此处截图，是第二次执行SQL，临时表的数据变化了（生成临时表的数据的SQL有好几个，每次执行获取的数据都会有部分变化）
因为有了合适的索引，趋近准确的统计信息，以及谓词下推（predicate push down），基数(Cardinality)的预估行数（Esitmted Row Size）为35.0545 与实际行数（Actual Number of Rows）为666， 这样即使循环次数为140. 总的访问记录数为140*666=93240 ， 这个是远远小于之前错误执行计划的138265650 。所以即使临时表的#Batch的统计信息有误，但是优化器还是生成了一个不错的执行计划。这样SQL的执行时间也就缩短到了1秒内.
这个案例仅仅是为了展示：统计信息的准确与否，会导致优化器生成的执行计划选择不同的表连接方式， 例如从嵌套循环（Nested Loops)变成Hash Join。 仅仅是为了说明统计信息准确的重要性。
作者：潇湘隐者 出处：http://www.cnblogs.com/kerrycode/
标签：pr,偏差,PdaRecords,信息,Server,WDPM,索引,SQL 来源： https://www.cnblogs.com/Leo_wl/p/10743875.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。