來自非聚集索引的鍵查找總是比進行查找的第二個查詢慢嗎？

我在我的系統中註意到，每當在查詢中使用非聚集索引時，該查詢還必須進行鍵查找以獲取被選中的附加欄位，對我來說執行兩個查詢會更快。

第一個使用非聚集索引僅將鍵欄位插入臨時表（因此不執行鍵查找），第二個使用該臨時表連接回原始表以在鍵上對其進行過濾，然後選擇我需要的領域。

當我注意到這一點時，我通常會查詢具有數億到數百億行的表。我不確定這是否與我在表首次載入到記憶體時消除鍵查找而是將鍵插入臨時表以便後續欄位查找查詢發生兩個表已經在記憶體中？

我將看到的時間差異通常也很重要，例如以分鐘為單位。

我可以想到幾種情況，這種方法可能是有益的。

1. 有時，您最終可能會得到一個執行計劃，該計劃會對行進行大量查找，然後最終在下游過濾掉（我注意到這一點，尤其是分頁查詢）。如果您只儲存過濾後的行，那麼需要解決的“手動查找”將更少。這種情況通常可以通過自連接來解決，並且不需要中間物化。
2. 查找總是使用嵌套循環。“手動查找”可能使用不同的連接類型 - 要查找的行的基數估計將在具體化時出現，並且可能與鼓勵這一點的原始估計不同。

對於上述兩種情況都不適用的情況（並且您只是具體化到一個臨時表中並獲得與沒有這一步並且沒有從改進的基數估計中受益的相同數量的嵌套循環查找）我希望這通常比沒有中間步驟的原始查詢慢（從表面上看，您正在做同樣的工作，但增加了一些額外的成本），但尚未對此進行測試。

您的表設計是否可以將來自鍵查找的INCLUDED列添加為非聚集索引中的列？

引用自：https://dba.stackexchange.com/questions/258569