使用提示鎖優化查詢

我有一個經常被呼叫的儲存過程。對於某些數據庫伺服器，它通常是每秒 20 次。不幸的是，因為不同的客戶端呼叫這個過程，我不能（在沒有對應用程序進行重大重新架構的情況下）將查詢分塊到表更新中。

最近數據庫性能下降了，一個非常簡單的更新需要 30-90 秒而不是毫秒。

到目前為止（查看伺服器上的資源等待），鎖貢獻了絕大多數等待（它的時間是第二個競爭者的 150 倍）。

儲存過程進行一些驗證，然後插入或更新現有記錄（現在所有記錄都是更新）。如果驗證失敗，則為 RAISERROR，並且錯誤會一直傳遞回客戶端（這是無法輕鬆分塊的主要障礙）。

儲存過程是

UPDATE dbo.TblHeartbeat
SET
   LastCheckedIn = GETUTCDATE(),
   NumberOfCheckIns = NumberOfCheckIns + 1,
   LastCheckInVersion = @Version,
   IPAddress = @IPAddress
WHERE
   MachineID = @MachineKey

我懷疑將其更改為 WITH(ROWLOCK) 將解決問題。不過，關於鎖的科學似乎並不多。意見各不相同，SQL 知道它在做什麼，不強迫它做某事，它會忽略提示，你應該實際上從表中刪除頁鎖以強制它使用行鎖。

我在尋找，

1. 這裡的正確方法是什麼。
2. 我可以在這種變化背後放置什麼科學
3. 我如何計算/欣賞這種變化的影響。
4. SQL 會忽略提示嗎？

在使用提示之前，我會檢查您正在更新的表上的索引；您可能需要 MachineID 上的聚集索引；沒有它，更新可能會被迫鎖定整個表以更新一行，這可能就是您所看到的。還要檢查表上的所有觸發器，確保它們已優化。

如果可以，請發布您的表架構或更新的執行計劃。

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