Sql-Server
（聚集索引）掃描正在進行時聚集索引是否被鎖定？
正如標題所說，這個問題很簡單。但是，我找不到任何參考來證實或反駁這一點。
導致我提出這個問題的問題是我有一個加入其他幾個視圖和表的視圖。其中一個表（我們稱之為表 A）在連接條件中的列上沒有覆蓋非聚集索引，而是發出了聚集索引掃描。
結果是所有其他也使用表 A AND 使用聚集索引掃描的查詢在第一個查詢之後等待（還沒有死鎖，因為我有一個很大的超時）。一旦我在表 A 上為連接列創建了一個非聚集索引，就不再使用聚集索引，並且查詢開始並行工作。
無論如何，如果我的假設是正確的，有沒有辦法檢測到鎖？我還沒有嘗試啟用任何與鎖定相關的跟踪標誌？我現在只使用了“sp_who2”和其他一些在這裡找到的查詢。
如果您以前偶然發現過這種情況，請分享您的想法。
還有很多很多的因素在起作用。
- 隔離級別。隔離級別之間的鎖定行為差異很大。有些根本不鎖定（讀取未送出、快照、rcsi）。預設的已送出讀取會在必要時暫時鎖定它讀取的行。可重複讀取和可序列化保持鎖定並最終鎖定所有內容，許多開發人員部署可序列化卻沒有意識到他們這樣做了。
- 掃描目的。掃描讀取彼此兼容，因此無論鎖定什麼，它們都不會阻塞。如果您的掃描阻止了其他掃描，則它們必須是更新掃描，它們彼此不兼容。同樣，即使在進行更新掃描時，快照隔離級別（包括 rcsi）也不會阻塞。
- 鎖定粒度，基於基數估計。掃描可以選擇行、頁或行集級別的粒度。表掃描可能會選擇頁鎖。
- 索引頁鎖/行鎖配置，您無意中更改了它。您應該恢復更改，因為它不基於任何測量和根本原因分析。膽量的感覺對調查沒有任何作用。
- 鎖升級
- 存在行外 LOB 數據時的行穩定性要求
- 其他
我建議您按照擷取單個操作的等待統計資訊中描述的過程來擷取您觀察為阻塞的掃描的等待統計資訊。如果他們確實阻塞了表掃描操作持有的鎖。如果場景確實如您所描述的那樣（讀取掃描與其他讀取操作），那麼沒有理由阻塞，所以會有其他事情在起作用。您也可以試一試 sp_whoisactive 。