減少鍵查找

我正在使用 SQL 伺服器，我一直在仔細研究鍵查找的概念，

http://blog.sqlauthority.com/2009/10/07/sql-server-query-optimization-remove-bookmark-lookup-remove-rid-lookup-remove-key-lookup/

因此，如果您有一個鍵查找，您可以使用“包含”列創建一個索引，以覆蓋您在 select 語句中擁有的非索引列。

例如，

SELECT ID, FirstName FROM OneIndex WHERE City = 'Las Vegas'
GO

該索引將包括一個鍵查找，

CREATE NONCLUSTERED INDEX [IX_OneIndex_City] ON [dbo].[OneIndex]
(
[City] ASC
) ON [PRIMARY]
GO

但是這個將刪除密鑰查找，

CREATE NONCLUSTERED INDEX [IX_OneIndex_Include] ON [dbo].[OneIndex]
(
City
) INCLUDE (FirstName,ID) ON [PRIMARY]
GO

我的意思是這對性能有多大影響？密鑰查找的操作員成本為 0.295969 (99%)，但這到底意味著什麼？

你怎麼知道那裡需要第二個索引，什麼時候你試圖添加太多索引而不值得？

在我看來，某些查詢可以包括索引掃描、鍵查找，而且執行起來似乎仍然非常快。

假設電話公司有一個電話號碼列表，包括客戶是誰、他們住在哪裡、他們的帳單號碼是什麼等等。主鍵可以是電話號碼。

他們給你白頁。這就像一個非聚集索引，按名稱排序，包括地址等列。

如果您想找到書中所有的 Farley，並且對他們的地址感興趣，那麼白頁就是您所需要的。您可以快速查找 Farleys（查找 Fs，等等），然後您就獲得了所需的所有資訊。

但是，如果您想要他們的帳單號碼，那麼您需要進行查找。您可以快速找到 Farleys 的所有電話號碼，但是您需要獲取其中的每一個（數百個）並在按電話號碼排序的主（聚集）索引中執行另一個 Seek（查找）。這些中的每一個都與尋找 Farleys 的成本大致相同，從而使您的查詢執行更差幾個數量級。

而且有一個門檻。到了某個時候，數據庫會意識到只瀏覽聚群索引的每一頁，檢查每條記錄以查看它是否感興趣，這樣會更快。

說真的 - 擺脫查找。您的查詢現在可能很快，但可能無法擴展。

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