前言：

????????由于網站訪問壓力的問題，綜合分析各種因素后結合實際情況，采用數據庫讀寫分離模式來解決當前問題。實際方案中采用“事務發布”模式實現主數據庫和只讀數據庫的同步，其中：

　　　　發布服務器1臺：sql2005，推送訂閱模式

　　　　訂閱服務器2臺：sql2005

問題：

????????以上方案后實施后，數據同步正常，但從日志中發現了死鎖情況。錯誤提示如：事務(進程 ID *)與另一個進程被死鎖在 鎖 資源上，并且已被選作死鎖犧牲品。請重新運行該事務。

查詢一些資料后，確定是數據同步的同時資源被鎖，同時用戶訪問頁面請求，導致死鎖產生，按照事務優先級，應用程序產生死鎖。

解決方法：

??????? 找到大致思路后，查詢了一些資料，大部分資料顯示是死鎖如何產生，如果跟蹤日志，然后根據日志優化查詢等方向，嘗試一些方案后死鎖減少，但并沒有徹底解決，最后轉換思路，從項目實際情況來看，主要是資訊信息的查詢，對查詢結果的安全性要求相對不高，所以可以接受“臟”數據的情況，在某種情況下又能提升查詢的性能，于是在一些查詢頻繁和數據量比較大的幾個表的select語句中加入with(nolock)，死鎖問題徹底解決。

建議：

??????? 處理一個數據庫死鎖的異常時候，其中一個建議就是使用 NOLOCK 或者 READPAST，對于非銀行等嚴格要求事務的行業，搜索記錄中出現或者不出現某條記錄，都是在可容忍范圍內，所以碰到死鎖，應該首先考慮，我們業務邏輯是否能容忍出現或者不出現某些記錄，而不是尋求對雙方都加鎖條件下如何解鎖的問題。

NOLOCK 和 READPAST 都是處理查詢、插入、刪除等操作時候，如何應對鎖住的數據記錄。但是這時候一定要注意NOLOCK 和 READPAST的局限性，確認你的業務邏輯可以容忍這些記錄的出現或者不出現：?
簡單來說：

NOLOCK 可能把沒有提交事務的數據也顯示出來．

READPAST 會把被鎖住的行不顯示出來?

不使用 NOLOCK 和 READPAST ，在 Select 操作時候則有可能報錯誤：事務(進程 ID **)與另一個進程被死鎖在 鎖 資源上，并且已被選作死鎖犧牲品。?

做此記錄，希望給遇到同樣的問題的朋友一些幫助。

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的读写分离,读写分离死锁解决方案,事务发布死锁解决方案,发布订阅死锁解决方案|事务(进程 ID *)与另一个进程被死锁在 锁 资源上，并且已被选作死锁牺牲品。请重新运行该事务...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。