https://blog.csdn.net/qq_16605855/article/details/89183976

分析步驟：

現象還原：

1.查看redis死鎖日志：show?engine?innodb?status

2.分析死鎖日志

3.看壓測吞吐是否過大

?

遇到的現象：壓測吞吐放的很小還是會出現死鎖現象，死鎖導致原因是行級鎖，壓測腳本是設置計數器數據遞增到一定量開始重頭開始遞增數據，比如1-1000遞增后又開始從1遞增。這個時候如果服務一個線程在處理key 2,第二輪遞增開始了，又有一個線程在處理key 2.。那么會出現兩個線程同時處理一個數據庫key，其中一個已經持有鎖了，所以另一個只能等待

就會出現

判斷是表鎖還是行級鎖的方法：

把壓測數據設置不重復從頭遞增，讓一直遞增一定數量，不重復，如果業務那好出現死鎖那就是表鎖，如果沒出現死鎖那說明就是行鎖

表鎖和行鎖的區別：

表鎖指的是事務訪問鎖住了整張表，那么其他請求進來都會出現死鎖訪問不了 表

?

行鎖指是一個事務訪問鎖住了這一行，也就是這一行的key，那么其他請求訪問這個key就會出現死鎖

?

這次壓測中最后測試是行鎖，也就是線程同時操作同一個key產生的，但是生產上不會出現同時對一個key進行操作的情況，而且對于我們現有業務壓測造成死鎖到 死鎖釋放時間很短，不會對壓測性能結果造成太大影響，所以在我們這個業務壓測場景下我們選擇了忽略這個死鎖現象

注：insert,updata,delete在壓測腳本會出現重復數據時，并且服務多線程處理，那么就會出現死鎖的現象，比如線程1在insert? ?key1，線程2在delete key1,那么線程1占有鎖還沒釋放，線程2delete鎖就會出現死鎖現象，但就我們的業務來說不會在添加冰箱的同時刪除冰箱

總結

以上是生活随笔為你收集整理的压测遇到数据库死锁的全部內容，希望文章能夠幫你解決所遇到的問題。

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