Question

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

我在hugeTable上添加了一个PK，并创建了一个索引，覆盖了pivot子查询的所有列。然后80％的成本是封面索引上的“Index Spool（Eager Spool）”。（它首先进行了索引扫描（4％））。

如何避免hugeTable上的“索引假脱机”？

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

Answer 1

似乎索引假脱机可能是因为你正在进行外部申请。查询优化器知道它将在整个apply中命中子查询中的每一行，因此优化器将结果集删除到tempdb中。这是一个猜测，没有实际的查询计划。

您的查询成本的很大一部分总是会被分配到某处。换句话说，没有零成本查询这样的东西。这里的技巧是你可以用其他东西来提高索引假脱机操作（最大的成本操作）的性能。在外部申请的情况下......也许不是。

我建议在dba.stackexchange.com上重新询问这个问题并提供实际的xml计划。您可能会以这种方式获得更彻底的分析。您可能会发现在这种情况下，热切换线轴是您的最佳选择。

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

同时确保您的统计数据和缓存清晰，并且每轮测试都是最新的。

创建PK和索引后的索引假脱机？

1 个答案: