熟悉或者了解數(shù)據(jù)庫的朋友都知道鎖的概念，這里不做過多的解析！鎖的種類有很多，不同數(shù)據(jù)庫的鎖管理方式也不同。這里主要談下MySQL innodb引擎下的死鎖。

死鎖通俗的來講就是2個事務(wù)相互請求對方持有的鎖，這樣就會造成2個事務(wù)相互等待對方釋放的鎖資源，于是這就是死鎖。事務(wù)A事務(wù)B

begin;

select * from t where a = 1 for update;begin;

select * from t where a = 2 for update;

select * from t where a = 2 for update;

#等待

select * from t where a = 1 for update;

#ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction

首先INNODB引擎不會回滾大多數(shù)的異常，但死鎖除外。再發(fā)現(xiàn)死鎖后，Innodb會立即回滾其中一個事務(wù)(這里回滾依據(jù)，會設(shè)計到權(quán)重問題)。例子中事務(wù)B被回滾！這是最常見的一種死鎖例子。

MySQL還有另外一種死鎖情況：當(dāng)前事務(wù)持有待插入記錄的下一個記錄的X鎖(排他鎖)，但此時等待的隊列中存在一個S鎖的請求，則可能會發(fā)生死鎖。首先創(chuàng)建一個測試用的表，并插入數(shù)據(jù)：

create table test( a int primary key) engine=innodb;

insert into test values (1),(2),(4),(5);時間事務(wù)A事務(wù)B

1begin;

2begin;

3select * from test where

a = 4 for update;

4select * from test where

a<=4 lock in share mode;

#等待

5insert into test values (3)

ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction

6#事務(wù)獲得鎖，正常運行

事務(wù)A中已經(jīng)對記錄4持有了X鎖，但會話A插入記錄3的時候會導(dǎo)致死鎖發(fā)生。這個問題產(chǎn)生是由于事務(wù)B中請求記錄4的S鎖而發(fā)生等待，但之前請求鎖對于主鍵記錄1、2都已經(jīng)成功，若再時間5能插入記錄，那么事務(wù)B在獲取記錄4持有的S鎖后，還需要向后獲得記錄3的記錄，這顯得不合理。于是INNODB引擎在這里主動選擇死鎖。

總結(jié)

以上是生活随笔為你收集整理的mysql死锁分析_MySQL死锁分析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。