0

我有以下查询。它运行缓慢，但在没有 PK 时会获得一些价值hugeTable。估计的执行计划显示一半的成本是“RID Lookup (Heap) [hugeTable] 51%”。

我添加了一个 PKhugeTable并创建了一个索引，涵盖了枢轴子查询的所有列。那么80%的成本就是封面索引上的“Index Spool（Eager Spool）”。（它首先进行了索引扫描（4%））。

如何避免 hugeTable 上的“Index spool”？

select ..., [...], [...], ...
from ....
    T1 ...
    outer apply (
        select k1, k2, [...], [...], ...
        from (
            select k1, k2, col, value
            from hugeTable 
            where k1 = T1.K1 and k2 = T1.K2
            ) p pivot (sum(value) for col in ([...], [...], ...)) as pvt
        ) a pvt
4

1 回答 1

0

似乎索引假脱机很可能是因为您正在执行外部应用。查询优化器知道它将在整个应用过程中命中子查询中的每一行，因此优化器将结果集放到 tempdb 中。这是一个猜测，手头没有实际的查询计划。

您的大部分查询成本总是会分配到某个地方。换句话说，不存在零成本查询。这里的技巧是你能不能用别的东西来提高那个索引假脱机操作（最大成本操作）的性能。在外部应用的情况下......也许不是。

我建议在 dba.stackexchange.com 上重新提出这个问题并提供实际的 xml 计划。这样你可能会得到更彻底的分析。您可能会发现在这种情况下，Eager spool 是您的最佳选择。

此外，您可以尝试使用索引提示作为测试，看看您是否可以强制使用备用计划。然后，您实际上可以将一个计划的性能与另一个计划进行比较。除了测试之外，我很少推荐索引提示。如果您发现它实际上更快，我仍然会研究为什么优化器不使用它。

还要确保您的统计数据和缓存对于每一轮测试都是干净的、最新的和新鲜的。

于 2013-10-15T14:31:17.263 回答