使用 EarlyTermination Timeout 优化查询是否值得？

Question

在运行Ola 的 IndexOptimize重建所有索引和统计信息后，我立即清除了数据和计划缓存，并运行了一个非常复杂的丑陋查询来获得其性能的基线。查询实际计划显示 ReasonForEarlyTermination=Timeout 和 Est Rows 和 Actual Rows 的偏差（与 est. 相比，实际行因子为 10,000）。

我想知道这种行数的不平衡是否可能是超时的结果 - 我认为在索引和统计信息重建之后应该是合适的？

如果无法更改查询本身，那么优化以 ReasonForEarlyTermination=Timeout 结尾的查询是否有意义？由于我打算做一些索引调整并重新运行查询，所以不是不可能确定可能改进的结果，因为下一个查询计划创建肯定会再次超时，因此可能会有所不同，结果不同?

技术 详细信息：Sql Server 2008 R2 开发。埃德。10.50.6000.34 DB Comp. 80级。

Answer 1

我想知道这种行数不平衡是否可能是超时的结果

几乎无一例外，没有。在优化开始之前执行初始基数估计。随后的优化器转换可能需要计算新的估计值。没有一般规则可以说明哪个估计更“准确”。

有关超时原因的其他信息，请参阅此相关问题：

没有找到足够好的计划的查询

我认为在索引和统计信息重建后应该是合适的？

您有“一个非常复杂的丑陋查询”。在这种情况下期望基数估计器能很好地工作是不合理的。尝试根据单列（可能是采样的）统计直方图和单值密度信息计算自己的估计值，以了解这一点。

随着查询复杂性的增加，估计的质量往往会下降。这是不可避免的，如果您认为一个估计的输入通常是另一个估计的输出。因此，错误趋于累积。使用“丑陋”（阅读：非关系或其他难以估计的）条件使情况变得更糟。

如果无法更改查询本身，那么优化以 ReasonForEarlyTermination=Timeout 结尾的查询是否有意义？

当然（但与任何其他有问题的计划没有什么不同）。在一般的，可以中断查询时，使用不同的语法，或者一百个不同的“招数”任何一个表达它可以使用。

即使查询本身无法更改，如果可以找到一个好的计划，也可以通过计划指南强制执行。更一般地说，添加新的统计信息和/或索引可以为优化器和基数估计器提供更好的信息。这也会以复杂的方式影响通过优化器的代码路径。我不会尝试列出在更改查询文本之外可以完成的所有事情。

...下一个查询计划创建肯定会再次超时，因此可能会有所不同，结果不同？

关键是通过提供更好的信息或数据访问方法，您通常会提高获得好的计划的机会。优化器不是随机的，因此对于数据库的给定状态，无论超时或其他终止原因如何，都会选择相同的计划。

当然，成功的真正关键是避免“非常复杂、丑陋”的查询。