創建PK和索引後的索引假脫機？

Question

我有以下查詢。它運行緩慢，但在hugeTable上沒有PK時獲得一些價值。估計的執行計劃顯示成本的一半是「RID查找（堆）[hugetable] 51％」。

我在hugeTable上添加了一個PK，並創建了一個索引來覆蓋pivot的子查詢的所有列。然後，80％的成本是封面索引中的「索引假脫機（快速假脫機）」。 （它確實索引掃描（4％））。

如何避免在巨大的表上的「指數軸」？

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計劃。您可能會以這種方式進行更徹底的分析。您可能會發現在這種情況下，eager spool是您的最佳選擇。

此外，您可以嘗試使用索引提示作爲測試，以查看您是否可以強制使用備用計劃。然後你可以比較一個計劃的表現和另一個計劃的表現。除了測試以外，我很少推薦索引提示。如果你發現它實際上更快，我仍然會研究爲什麼優化器不使用它。

此外，請確保您的統計信息和緩存清潔，並且每一輪測試都是最新且最新的。