mysql 死鎖問(wèn)題及死鎖權(quán)重分析

問(wèn)題發(fā)生過(guò)程：

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

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

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

tablbe 字段

id：主鍵 business_no為唯一索引字段，其他字段暫時(shí)無(wú)意義

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

上述sql在一個(gè)事務(wù)內(nèi),死鎖必定有兩把鎖。

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

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

查找代碼返現(xiàn)同一時(shí)刻,另外一個(gè)事務(wù)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)象不復(fù)核預(yù)期

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

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

理論是sql1 和 sql3 都有可能發(fā)生死鎖，因?yàn)閟q1在一個(gè)sql內(nèi)，sql2、slq3是分開的，

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

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

第一步懷疑有其他sql參與了，但是沒(méi)找到疑點(diǎn)sql。

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

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

感覺(jué)問(wèn)題快找到了，猜想sql1事務(wù)內(nèi)只有一個(gè)事務(wù)（他基本就是小權(quán)重的事務(wù)）。

那接下來(lái)分析日志驗(yàn)證：

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

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

在sql2和sql3之前還有sql4。

那猜測(cè)有事務(wù)4  中sql5  UPDATE table2 set  data2 = ‘345’ where id = 1;

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

接下來(lái)實(shí)際驗(yàn)證：

開啟事務(wù)1：

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

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

開啟事務(wù)2：

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

開啟事務(wù)3：

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

事務(wù)1：

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

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

4、問(wèn)題總結(jié)

msql行級(jí)鎖加鎖的過(guò)程。

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

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

最新評(píng)論