创建主键和索引后的索引假脱机？

Question

我有以下问题。它运行很慢，但当hugeTable上没有PK时，它会获得一些值。估计的执行计划显示，一半的成本是"RID查找(堆) hugeTable 51%“。

我在hugeTable上添加了一个PK，并为pivot的子查询创建了一个覆盖所有列的索引。然后80%的成本是“索引假脱机(渴望假脱机)”的封面索引。(它首先进行了索引扫描(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

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

查询开销的很大一部分总是会被分配到某个地方。换句话说，没有零成本查询这回事。这里的诀窍是，您可以使用其他方法来提高索引假脱机操作(开销最大的操作)的性能。在外部应用的情况下...也许不是。

我建议在dba.stackexchange.com上重新询问这个问题，并提供实际的xml计划。通过这种方式，您可能会得到更全面的分析。在这种情况下，您可能会发现热切的假脱机是您的最佳选择。

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

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