我有以下情況：存儲過程間歇性地使用兩個表。我必須同時執行這個sp（同時像50個）。這使我陷入約33％的僵局。 問題是：在這裏使用sp_getapplock是否合適？我所要做的就是添加：何時使用sp_getapplock
exec sp_getapplock @Resource = 'resource_name', @LockMode = 'exclusive',@LockTimeout = '60000', @DbPrincipal = 'dbo'
在交易的第一個命令，一切似乎是工作。除了併發性，但沒關係。令人不安的是我試圖做數據庫實際上應該做的事情。也許這種方法有更好的選擇或嚴重的缺點？
您現在可能已經解決了這個問題，但以防萬一。負載下的大型複雜數據庫幾乎可以不時遇到死鎖。對於數據庫來說，如果能夠確定是否會在後續的過程中爭用資源，那麼將很難預測到所需的程度。你可以做很多事情來減少死鎖，包括良好的索引，結構良好的表訪問等等（大量的信息）。然而，在這種情況下，您可能無法以避免死鎖的方式構造代碼，並且使用sp_getapplock絕對不是一件壞事。正如你所指出的那樣，它確實會造成瓶頸，因爲你不再具有併發性。但是消除死鎖的好處可能不僅僅是彌補性能方面的缺陷。不幸的是，我在我的一個SP中嘗試了類似的東西，但是調用sp_getapplock本身導致了死鎖 - 所以它並不總能保證解決問題。
從根本上說，它的確歸結於你試圖實現的目標。但要確保你使用的數據庫越複雜，你需要手動調整它的方面的機會就越多 - 它不會爲你做所有事情，這就是爲什麼仍然需要優秀的數據庫大師。我會說，除非你有一個特定的要求，SP是單線程的，使用sp_getapplock不應該是你第一次嘗試解決問題 - 我只使用了它3次或其他東西。然而，考慮到你的情況，我肯定會用它來解決你的問題，並不需要你瞭解SP的複雜內部，並且可能沒有任何不良副作用。最有可能的是，它可能會減慢 - 但聽起來你沒有注意到這一點？
HTH
有您已經閱讀[文件]（http://msdn.microsoft.com/en-us/library/ms191242（v = SQL.105）的.aspx）就減少死鎖和實施那些儘可能提出建議？ – Pondlife
是的，我做到了。問題是我不想修改存儲過程。特別是當這種方法似乎工作，除了我是新來的 – ren