错误的估计行数

Question

我正在尝试确定我有时在存储过程中遇到的问题。

我不得不说，存储过程在 select 子句中使用了 UDF（也许这就是问题的原因）但无论如何，不​​管它不是，下面是执行计划的一部分：

其中 Hash Match 的输出估计行数和非聚集索引 IX_Job_OperationID 上的 Index_Seek 估计值都是完全错误的：

我试图更新与索引 IX_Job_OperationID 相关的统计信息，即使使用 fullscan 选项，但它没有帮助。

UPDATE STATISTICS Job [IX_Job_OperationID] with fullscan

我也在使用 recompile存储中选项，因为给定提供的参数，所涉及的数据集可能会发生很大变化。

有人能指出我正确的方向并帮助我理解为什么即使更新了统计数据，估计值与实际值相差甚远？

这里是实际执行计划的链接

该执行计划导致总共 8,610,665 次逻辑读取，而其他以某种方式选择的更好的计划可能约为 122,692

Answer 1

根据您对问题的描述，UDF 不太可能是基数估计错误的原因。如果您想测试它，您可以尝试注释掉 UDF 并检查连接估计是否更改。

即使使用 更新了统计信息，也可能会出现基数估计错误FULLSCAN。SQL Server 创建的直方图可能无法以优化器创建足够好的计划的方式对您的数据进行建模，SQL Server 可能没有与连接数据完全匹配的直方图（您可以对内部和/或外部表进行过滤），您可能会加入使估计复杂化的多个列，等等。例如，Microsoft 在 SQL Server 2014 中发布的新 CE 中更改了一些连接基数估计计算。某些表的数据将更好地匹配旧 CE 的假设，而某些表的数据将更好地匹配新 CE 的假设。行政长官。

对于第一个估计问题（38999 估计行与 701680 实际行），根据您提供的内容，我只能建议阅读有关连接基数计算的内容。Microsoft为 SQL Server 2014 中的新基数估计器发布了一份白皮书。我还知道有一篇博文深入探讨了连接基数的内部原理。正如问题所写，有太多可能的原因无法给出一个好的答案。如果您需要进一步的指导，请发布实际的执行计划。

对于第二个估计问题（1 个估计行与 1546894 个实际行），请注意估计的行数是针对连接的内部循环的单次迭代。实际的行数是针对在连接的所有迭代中从表返回的所有行，因此它们通常不会与嵌套循环连接匹配。您所看到的情况很常见，不一定是问题的迹象。