mysql 死鎖問題及死鎖權重分析

問題發(fā)生過程：

1、生產(chǎn)發(fā)現(xiàn)死鎖一次

語句為sql1:UPDATE table set  data = ‘123’ where business_no = 'ABC';

該行數(shù)據(jù)的id=1， business_no = 'ABC'

tablbe 字段

id：主鍵 business_no為唯一索引字段，其他字段暫時無意義

2、查找發(fā)生死鎖問題原因

上述sql在一個事務內,死鎖必定有兩把鎖。

最開始對鎖的理解就是鎖主鍵、不清楚是否有其他鎖參與。

網(wǎng)上搜索發(fā)現(xiàn)update的where條件為唯一索引時候，sql會同時獲取兩把鎖，先獲取唯一索引business_no的鎖,再獲取主鍵id的鎖，所以必定同一時刻有先獲取id鎖，再獲取唯一主鍵鎖的sql。

查找代碼返現(xiàn)同一時刻,另外一個事務2執(zhí)行了以下sql

sql2：UPDATE table set  data = ‘123’ where id = 1;

sql3:UPDATE table set  data = ‘123’ where business_no = ‘ABC’；

現(xiàn)在發(fā)現(xiàn)了死鎖原因：

但是現(xiàn)象不復核預期

sql 1 先唯一鍵鎖、后 主鍵鎖

sql2 先主鍵鎖 、sql3后唯一鍵鎖

理論是sql1 和 sql3 都有可能發(fā)生死鎖，因為sq1在一個sql內，sql2、slq3是分開的，

按預期sql3發(fā)生死鎖錯誤的概率最大，但是代碼發(fā)生了8次死鎖全部是sql1發(fā)生了死鎖。

3、為啥sql1發(fā)生死鎖

第一步懷疑有其他sql參與了，但是沒找到疑點sql。

網(wǎng)上搜索發(fā)現(xiàn)了一個死鎖權重的概念。

大概意思是發(fā)生死鎖根據(jù)算法確定權重，權重小的事務會回滾。

感覺問題快找到了，猜想sql1事務內只有一個事務（他基本就是小權重的事務）。

那接下來分析日志驗證：

事務2還執(zhí)行了以下sql。

sql4：UPDATE table2 set  data2 = ‘123’ where id = 1;

在sql2和sql3之前還有sql4。

那猜測有事務4  中sql5  UPDATE table2 set  data2 = ‘345’ where id = 1;

讓后搜索日志發(fā)現(xiàn)同一時間有有sql5。

接下來實際驗證：

開啟事務1：

執(zhí)行：sql2：UPDATE table set  data = ‘123’ where id = 1;

執(zhí)行sql4：UPDATE table2 set  data2 = ‘123’ where id = 1;

開啟事務2：

執(zhí)行slq1:UPDATE table set  data = ‘123’ where business_no = 'ABC';

開啟事務3：

執(zhí)行sql5：UPDATE table2 set  data2 = ‘345’ where id = 1;

事務1：

執(zhí)行slq3：UPDATE table set  data = ‘123’ where business_no = ‘ABC’；

發(fā)現(xiàn)必sql1必死鎖異常且回滾，問題解決。

4、問題總結

msql行級鎖加鎖的過程。

mysql發(fā)生死鎖回滾的機制。

到此這篇關于MYSQL 根據(jù)唯一索引鍵更新死鎖問題的文章就介紹到這了,更多相關mysql唯一索引鍵更新死鎖內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論