zli*_*i89 9 sql-server optimization
我们知道,在优化过程中,备忘录结构被修剪,一些昂贵的替代计划被丢弃。我想知道是否有任何方法可以防止这种情况发生,让优化器只考虑每个可能的计划并从所有备选方案中选择最佳方案?
Pau*_*ite 13
我们知道,在优化过程中,备忘录结构被修剪,一些昂贵的替代计划被丢弃。我想知道是否有任何方法可以防止这种情况发生,让优化器只考虑每个可能的计划并从所有备选方案中选择最佳方案?
有,但我不宣传它,因为它会被误解和误用。在任何情况下,它都不会导致对计划空间的详尽搜索,因为只实现了有限的一组转换(通常会产生良好结果的转换)。
防止修剪和丢弃通常只会导致(很多)更长的编译时间,而不会对最终计划质量(如果有的话)有太大改善。
归根结底,这个问题是一个自然而合理的问题,但它建立在对 SQL Server 查询优化器目标的误解之上:它旨在快速为常见查询找到好的计划。它不是建立在专为穷举搜索而设计的框架之上。
如果您的实际情况可以从不同的优化方法中受益,您可以在 Connect 网站上说明情况(尽管我确实认为 Microsoft 不太可能投资必要的工程资源)。
我知道没有旋钮或跟踪标志可以以任何方式强制这种行为(尽管Paul White 在这里提到了一些跟踪标志,它们提供了更多的可见性并允许您哄骗某些行为 deltas)。
微软提供了大量的武器,但这个武器几乎可以保证 100% 的时间都正对着你自己的脚。第一次运行查询时,我认为您不希望 SQL Server 花费无限量的时间来构建计划的每一个可能的变体以获得所需的结果。正如@ypercube 所提到的,这可能是非常多的计划,并且会完全违背运行查询的目的。您首先运行查询的目标大概是在某个时候返回数据,对吗?并且“某个点”必须在某些阈值内,因为应用程序的某些层将强制执行各种查询/命令超时,并且用户只会等待很长时间才能加载页面...
| 归档时间: |
|
| 查看次数: |
229 次 |
| 最近记录: |