調查高 SQL 等待，特別是 LCK_M_U
最近我一直在為 SQL Server 性能而苦苦掙扎，儘管我們已經修復了配置中的大量基本錯誤，但它的性能仍然很差。為了澄清這不是整體性能，而是相當頻繁的超時（來自客戶端應用程序）。 以前我曾將記憶體視為一個原因，但現在這個問題已經解決了，我們仍然得到相同的行為。
查看來自管理數據倉庫的圖表，我可以看到 LCK_M_U/X/IX 導致了我們在使用者遇到超時時的大部分等待。我正在閱讀的所有內容都表明我需要查看正在執行的查詢和程序，但我還沒有找到任何針對我能理解的水平的東西。正如您在下圖中看到的那樣，鎖似乎會出現尖峰，這與使用者端的錯誤一致。是否有一個聰明的 DMV 或一些我可以解決的問題，以嘗試找出正在執行的正在創建鎖的查詢？是不是一味追根究底？如果資訊不清楚，任何指導都非常感謝和道歉。
從表中的 sp_WhoIsActive 收集數據是跟踪阻塞和鎖定問題的好方法。
如果您想查看所涉及鎖的更詳細資訊，可以使用@get_locks參數。或者，@get_task_info 和@get_additional_info通常會擷取足夠的資訊來確定原因。
如果收集的輸出不夠清晰，無法理解問題，請隨時附加到您的問題。
鎖往往會形成鏈，你總是對鏈頭的程序在做什麼感興趣。簡單地查看鎖定等待時間可能會產生誤導，因為許多程序可以等待很長時間（因此增加了等待時間統計資訊），但都被單個狗慢程序阻塞。您可能會看到一個合併點：因為當高級鎖（X 或 SCH_M）進入資源等待隊列時，授予的鎖必須與所有目前的被授權者和所有待處理的等待者兼容，**所有後續請求都在此之後排隊.
舉個例子：假設您有一個查詢在表上執行報告，假設需要 5 分鐘。它在他的桌子上持有一個 IS 鎖。此 IS 兼容所有正常操作（讀取和寫入）。一個需要 SCH_M 的請求進來了。與 IS 不兼容，所以他被排在了隊列中。現在突然之間，表上的所有其他活動都進入隊列，因為每個請求，讀取或寫入，都與這個服務員不兼容。所以突然間所有的鎖定時間都飆升了。5 分鐘後，慢速查詢完成（在 DB 術語中它“耗盡”），SCH_M 被授予，它在 5 毫秒內完成它的工作，其他所有人都可以自由繼續。這只是一個（極端）範例，它不一定是 SCH_M。這個想法是，只是等待時間並不能說明全部情況。
幸運的是，SQL Server 本身可以通過一個幾乎不為人知的功能向您報告阻塞鏈，稱為
blocked process threshold. 混合阻塞程序報告和DDL 事件通知，您將獲得一個完全自動化的解決方案。例如，請參閱我在MS SQL Server 第三方事務阻塞監控工具上的回答。
另一個觀察結果：您在 IX 上有 22.30% 的等待時間。這意味著發生了對象級鎖定。意圖鎖（IS、IX）是兼容的，因此 IX 被阻止的事實表明有人獲得了不兼容的對象級鎖。獲得 S 的掃描，或升級到 X的大更新。