鉴于优化器不能花费它需要的所有时间（它必须最小化执行时间并且不为它做出贡献）来探索所有可能的执行计划，它有时会被切断。
我想知道这是否可以被覆盖，以便您可以在需要时一直给优化器（或一定的毫秒数）。
我不需要这个（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)：给优化器更多时间在这里没有任何价值。