非過濾列上的主鍵索引具有非常高的總鎖定等待時間
我正在看
激進索引：總鎖定等待時間 > 5 分鐘（行 + 頁），平均等待時間較短
在我們的一張桌子上通過BlitzIndex發出警告，我不太明白會發生什麼。有問題的索引與我們表上的主鍵有關：
ALTER TABLE [Authentication].[Tokens] ADD CONSTRAINT [PK_Authentication.Tokens] PRIMARY KEY CLUSTERED ( [TokenID] )為了完整起見，這裡是表結構的要點：
CREATE TABLE [Authentication].[Tokens]( [TokenID] [int] IDENTITY(1,1) NOT NULL, ... other columns here)BlitzIndex 報告以下統計數據：
Reads: 10,066,849 (2,259,000 seek 934,476 scan 6,873,373 lookup) Writes:1,399,277, 314 rows; 1.1MB我有些困惑。我們不會查詢/過濾掉這一列（如
SELECT ... WHERE TokenID = 1）。我唯一的猜測是該表可能被經常讀取，並且使用預設的 SQL 鎖定策略大量查詢相互碰撞？我願意接受任何建議或回饋，對於一個看似簡單和良性的表格。
請注意，您正在談論的是 a
PRIMARY KEY CLUSTERED（這意味著它是表本身），因此您不需要像WHERE TokenID = 1命中該索引這樣的查詢。從您的場景中，大多數讀取來自查找（您了解什麼是查找讀取方法嗎？）這意味著大多數查詢類似於SELECT TokenID, Column2, Column3 WHERE Column2 = 1並且您有一個不包括 TokenID、Column2 和 Column3 的 Column2 索引。以下是我將如何解釋你得到的輸出：
讀取：10,066,849（2,259,000 查找 934,476 掃描 6,873,373 查找）
- 2,259,000 次查找：這是一個相當大的值，但查找通常是訪問索引的最佳方法，這裡幾乎沒有改進的餘地。
- 934,476 掃描：通常是最差的訪問方法，但這個值與其他值相比可能不會對第一次修復產生最大的影響。
- 6,873,373 次查找：迄今為止最大的數字，值得關注，因為這可能是由於一些查詢重複命中非聚集索引而導致的，這些索引可以改進為進行查找。
寫入：1,399,277，314 行；
- 這些可能會導致讀取阻塞或因此而被阻塞，因此如果我可以使這些讀取更快地完成它們的工作（例如 通過改進索引或查詢
lookups來調整成為），那麼讀取將不得不等待寫入完成（反之亦然）將減少。seeks有了這些資訊，我將在查詢表的查詢中搜尋
[Authentication].[Tokens]正在執行查找讀取的內容。一旦它們得到改進，我將sp_BlitzIndex再次執行以測量調整的結果。進一步閱讀：
Brent Ozar 解釋了sp_BlitzIndex Aggressive Indexes以及如何修復 sp_BlitzIndex Aggressive Indexes 警告。
Pinal Dave 有一篇關於SQL SERVER – Removing Key Lookup的文章