如何處理MySQL死鎖問題

小編給大家分享一下如何處理MySQL死鎖問題，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

MySQL里的鎖兼容列表大體是這樣的關(guān)系，如果第一次看會有些暈，感覺抓不住重點，其實有一點小技巧。

首先InnoDB實現(xiàn)了兩種類似的行鎖，即S(共享鎖）和X(排他鎖），而InnoDB層面的表級意向鎖有IS(意向共享鎖）和IX9意向排他鎖），意向鎖之間是互相兼容的，這句話很重要，按照這個思路里面一半的內(nèi)容就明確了。而另外一部分則是S和X的兼容性。帶著S鎖和X鎖的組合都是互相排斥，只有一類場景例外，那就是都是S鎖，是兼容的。所以這個圖按照這個思路幾乎不用記就能基本理解了。

看起來S鎖的組合是很柔和的，從這種場景來看保持兼容，那么出死鎖的概率應(yīng)該很低吧，其實在RR,RC隔離級別下我們可以逐步擴(kuò)展然后舉一反三。

如果S鎖的組合在兩個會話中是互相兼容，那么接下來的X鎖的組合就是互相排斥的。

那么在兩個會話并發(fā)的場景下，死鎖的步驟如下：

mysql> create table dt1 (id int unique

Query OK, 0 rows affected (0.03 sec)

會話1：

begin;

select *from dt1 lock in share mode; --顯式共享鎖

會話2：

begin;

select *from dt1 lock in share mode; --顯式共享鎖

會話1：

insert into dt1 values(1); --阻塞

會話2：

insert into dt1 values(2); --觸發(fā)死鎖

所以上面的語句特點很明顯，插入的數(shù)據(jù)分別是1和2，看起來互補沖突也不行。

我們進(jìn)度稍快一些，我們可能很少看到直接聲明share mode的方式，但是有很多時候由其他的場景會觸發(fā)，其中的一個主要原因就在于對于duplicate數(shù)據(jù)的檢查會開啟S鎖。這是比較特別的一點，需要注意。

按照這一點來擴(kuò)展，很容易就可以擴(kuò)展到3個會話中。

會話1只是負(fù)責(zé)插入一條數(shù)據(jù)，會話2,3也緊接著插入一條記錄（會話2,3自動提交），但是因為唯一性索引的檢查，會導(dǎo)致會話2和會話3都開啟了S鎖，因為兼容，所以暫時還沒影響。如果會話1正常提交，會話2,3的檢查會生效，導(dǎo)致數(shù)據(jù)插入不了，違反唯一性約束，但是我們反其道而行，就可以用一個rollback來釋放鎖，緊接著會話2和會話3都會獲得S鎖成功，緊接著獲得X鎖，細(xì)節(jié)算法就不說了。這個時候互相阻塞，導(dǎo)致會話3產(chǎn)生死鎖，會話2的數(shù)據(jù)插入依然會成功。

會話1：

begin;

insert into dt1 values(1);

會話2：

insert into dt1 values(1);

會話3：

insert into dt1 values(1);

會話1：

rollback;

看起來很精巧的小測試，但是里面蘊含這大道理，比如按照這個思路，如果后面的兩個語句都是delete，也會觸發(fā)死鎖。有的時候我們可以正面來圖例，或者通過死鎖日志來推理。給我的一個啟發(fā)是太極。

放在鎖的角度來理解就會好很多。

用一張不太形象的圖表示就是，左邊的部分是insert操作在會話1中，右邊的是在會話2和會話3中，都持有S鎖，然后會因為同樣的原因事務(wù)回滾后，他們的S鎖會升級為X鎖導(dǎo)致死鎖發(fā)生。

按照這個思路，我們可以繼續(xù)擴(kuò)展出幾個場景。比如delete的方式。

按照這樣的思路，可以構(gòu)建出很多的死鎖場景來。

以上是“如何處理MySQL死鎖問題”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對大家有所幫助，如果還想學(xué)習(xí)更多知識，歡迎關(guān)注億速云行業(yè)資訊頻道！