是否可以为优化器提供更多或所有需要的时间？

Question

考虑到优化器不能花它需要的所有时间（它必须最小化执行时间而不是贡献它）来探索所有可能的执行计划，它有时会被切断。

我想知道这是否可以覆盖以便您可以在需要时（或一定数量的毫秒）始终提供优化器。

我不需要这个（atm），但我可以想象一个场景，一个复杂的查询在一个紧密的循环中执行，你想提出最佳计划并事先缓存它。

当然，你有一个紧密的循环，你应该重写查询，这样它就会消失，但请耐心等待。

这更多是出于好奇而提出的问题，也是为了查看短路优化和完整优化之间有时是否存在差异。

事实证明，您可以使用跟踪标志 2301 为优化器提供更多时间。这不完全是我所要求的，但它很接近。

我在这方面找到的最佳信息是Ian Jose 的SQL Server 2005 SP1中的查询处理器建模扩展。

小心使用这个跟踪标志！但是在提出更好的计划时它会很有用。也可以看看：

• Grant Fritkey标记为“优化级别”的文章。
• 在升级到 SQL Server 2008 之前……作者：Brent Ozar。
• Microsoft 支持在高性能工作负载中运行时的 SQL Server 优化选项。

我正在考虑具有大量连接的查询，其中连接顺序的解决方案空间呈指数级增长。SQL Server 使用的启发式方法非常好，但我想知道如果优化器有更多时间（在几秒甚至几分钟的范围内），它是否会提出不同的顺序。

Answer 1

下一步，跟踪标志2301，还有8780这确实使优化“更加努力地工作”，因为它只是给它更多的时间（不是无限的，如详细说明这里（俄罗斯），并不太详细这里）做它的事。

俄文文章原作者英文详细说明。其中包括作者自己的警告：

不建议在生产中使用它。

将两者结合并应用它们（非常有选择地通过查询提示 OPTION (QUERYTRACEON 2301, QUERYTRACEON 8780) 到 4 级嵌套内联 TVF 的查询（其中只有底部的一个可以做任何实际工作，上层将关联结果通过 EXISTS 子查询）产生了一个很好的 MERGE JOIN 和几个 LAZY SPOOL，将执行时间减少了一半。

Answer 2

不，你不能。

您可以通过了解查询的工作原理（复杂的野兽，无需彻底了解它）来使查询“优化器友好”。我建议如果你的事情对时间很重要，那么修复查询而不是改变 SQL Server 的运行方式。

例如，您想知道随着数据量 + 数据分布的变化，查询何时开始缩放效率低于 O(n)：为优化器提供更多时间在这里没有任何价值。