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

鉴于优化器无法花所有需要的时间（它必须使执行时间最小化并且不做任何贡献）来探索所有可能的执行计划，因此有时它会被切断。

我想知道是否可以覆盖它，以便您可以在需要的所有时间（或一定的毫秒数）内给予优化器。

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

当然，它存在一个死循环，您应该重写查询，以便它消失但请耐心等待。

出于好奇，这更多是一个问题，还需要了解短路优化和完整优化之间有时是否存在区别。

事实证明，您可以使用跟踪标志2301给优化器更多时间。这并不是我所要的，但它接近了。

我发现的最佳信息是Ian Jose 在SQL Server 2005 SP1中的查询处理器建模扩展中。

请谨慎使用此跟踪标志！但是在提出更好的计划时可能会很有用。也可以看看：

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

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

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

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

不建议在生产中使用它。

合并两者并将其应用（非常有选择地通过查询提示OPTION（QUERYTRACEON 2301，QUERYTRACEON 8780）来查询4层嵌套内联TVF（其中只有底部的一个会做任何实际工作，而高层会进行实际工作）通过EXISTS子查询）产生了很好的MERGE JOIN和几个LAZY SPOOL，将执行时间减少了一半。

不，你不能。

通过了解查询的工作方式（复杂的野兽，不必从内而外地了解它），可以使查询“对优化程序友好”。我建议，如果您对时间要求如此严格，则应修复查询，而不要更改SQL Server的运行方式。

例如，您想知道当数据量+数据分布发生变化时，查询何时开始以小于O（n）的效率开始扩展：给优化器更多的时间在这里没有任何价值。