事務(進程 ID 133)與另一個進程被死鎖在 鎖 資源上，並且已被選作死鎖犧牲品的解決方案

並發大了，經常出現這個提示：

/”應用程序中的服務器錯誤。
事務(進程 ID 133)與另一個進程被死鎖在 鎖 資源上，並且已被選作死鎖犧牲品。請重新運行該事務。
說明: 執行當前 Web 請求期間，出現未經處理的異常。請檢查堆棧跟蹤信息，以了解有關該錯誤以及代碼中導致錯誤的出處的詳細信息。

異常詳細信息: System.Data.SqlClient.SqlException: 事務(進程 ID 133)與另一個進程被死鎖在 鎖 資源上，並且已被選作死鎖犧牲品。請重新運行該事務。

源錯誤:

執行當前 Web 請求期間生成了未經處理的異常。可以使用下面的異常堆棧跟蹤信息確定有關異常原因和發生位置的信息。

估計就是搶鎖造成的，查看了這篇文章終於找到了解決方案：SELECT COUNT(*) FROM Example WITH(NOLOCK)    ，加上WITH(NOLOCK)就可以了

原文地址

 

NOLOCK

NOLOCK在概念上類似於READ UNCOMMITTED隔離級別，並且只針對於SELECT查詢語句，它不會獲取表的共享鎖，換句話說不會阻止排它鎖來更新數據行。當我們對表進行NOLOCK有什么好處呢？它能夠提高並發性能，因為此時SQL Server數據庫引擎不必去維護共享鎖，由於不會對正在讀取的表獲取共享鎖，所以可能導致未提交的事務也會被讀取，所以此時缺點顯而易見將導致臟讀

SELECT COUNT(*) FROM Example WITH(NOLOCK)

READPAST

當在表中用READPAST指定提示時此時SQL Server數據庫引擎在返回結果集時將不會返回鎖定的行或者數據頁。它除了和NOLOCK一樣不會導致查詢阻塞外，因為不會返回鎖定的行記錄所以其優點好包括不存在臟讀。但是其缺點則是因為不包含鎖定的行記錄但是很難保證結果集或者修改語句是否包含我們所必須需要返回的行。有可能在我們的業務邏輯中，需要返回我們必須需要的行。它的使用方式和NOLOCK一樣

SELECT COUNT(*)FROM Example WITH(READPAST)

UPDLOCK

UPDLOCK只是針對於表中的某一行記錄來鎖定從而阻止其他操作對該行的數據更新，說到這里想必我們已經明了，UPDLOCK是行級別，而排它鎖則是表級別，二者不可同日而語。也就說當我們對某一行添加UPDLOCK提示時並不會阻塞其他查詢操作

BEGIN TRAN
 select * from Example WITH (UPDLOCK) where SaleID = 1
此時我們再來開一個窗口進行查詢，如下：
select * from Example

HOLDLOCK

使用HOLDLOCK提示時，此時查詢將鎖定表且被強制序列化，直到事務完成，才會被釋放，其類似於SERIALIZABLE最高隔離級別

BEGIN TRAN
 select * from Example WITH (UPDLOCK,HOLDLOCK) where SaleID = 1