1、找到并確定你的死鎖日志

方式1：基于MySQL錯誤日志

方式2：基于SHOW ENGINE INNODB STATUS命令查看最近發(fā)生的死鎖日志

方式3：咨詢你的DBA吧！

2、分析你的死鎖日志

• 確定死鎖發(fā)生的時間
• 確定死鎖發(fā)生的順序
• 確定死鎖發(fā)生的位置以及觸發(fā)的SQL內(nèi)容

3、確定死鎖原因

• MySQL順序加鎖順序解鎖（公平鎖）
• 死鎖日志中出現(xiàn)的鎖，不論是等待的鎖，還是持有的，都是每個事務(wù)已經(jīng)擁有的鎖結(jié)構(gòu)

4、拓展：特殊情況加鎖引起的死鎖

?? 是不是每次看到死鎖日志就頭大？

?? 明明只是簡單的INSERT操作，數(shù)據(jù)庫卻神秘"卡死"？

看完本文，讓你3步快速定位死鎖原因！

1、找到并確定你的死鎖日志

方式1：基于MySQL錯誤日志

• 進(jìn)入MySQL
• 檢查innodb_print_all_deadlocks變量：

SHOW VARIABLES LIKE 'innodb_print_all_deadlocks';

• 如果innodb_print_all_deadlocks變量的值為OFF，則需要將其設(shè)置為ON以開啟死鎖日志。

SET GLOBAL innodb_print_all_deadlocks = 1;

• 退出MySQL，查看下面的日志

/usr/local/mysql/data/mysqld.local.err

方式2：基于SHOW ENGINE INNODB STATUS命令查看最近發(fā)生的死鎖日志

輸入該命令后，你需要去輸出的信息中找到如下關(guān)鍵字

------------------------ 
LATEST DETECTED DEADLOCK 
------------------------

后面的內(nèi)容即是最近一次發(fā)生的死鎖的內(nèi)容

方式3：咨詢你的DBA吧！

專業(yè)的事情交給專業(yè)的人來！DBA會幫你找到最近的死鎖信息的！

2、分析你的死鎖日志

現(xiàn)在我們已經(jīng)拿到了死鎖日志

2025-04-19 13:39:45 0x3079da000
*** (1) TRANSACTION:
TRANSACTION 10047, ACTIVE 10 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 1136, 1 row lock(s)
MySQL thread id 8, OS thread handle 13013229568, query id 113 localhost root updating
DELETE FROM t1 WHERE i = 1
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 44 page no 3 n bits 72 index PRIMARY of table `itsuka`.`t1` trx id 10047 lock_mode X locks rec but not gap waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 0: len 4; hex 80000001; asc     ;;
 1: len 6; hex 00000000273e; asc     >;;
 2: len 7; hex ad000001210110; asc     !  ;;

*** (2) TRANSACTION:
TRANSACTION 10048, ACTIVE 21 sec starting index read
mysql tables in use 1, locked 1
4 lock struct(s), heap size 1136, 2 row lock(s)
MySQL thread id 6, OS thread handle 13012672512, query id 114 localhost root updating
DELETE FROM t1 WHERE i = 1
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 44 page no 3 n bits 72 index PRIMARY of table `itsuka`.`t1` trx id 10048 lock mode S locks rec but not gap
Record lock, heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 0: len 4; hex 80000001; asc     ;;
 1: len 6; hex 00000000273e; asc     >;;
 2: len 7; hex ad000001210110; asc     !  ;;

*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 44 page no 3 n bits 72 index PRIMARY of table `itsuka`.`t1` trx id 10048 lock_mode X locks rec but not gap waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 0: len 4; hex 80000001; asc     ;;
 1: len 6; hex 00000000273e; asc     >;;
 2: len 7; hex ad000001210110; asc     !  ;;

*** WE ROLL BACK TRANSACTION (1)

通常我們拿到的死鎖日志如上所示

接下來我們要做的事情包括：

（1）確定死鎖發(fā)生的時間

2025-04-19 13:39:45 0x3079da000
*** (1) TRANSACTION:

首先，我們基于死鎖日志了解到死鎖發(fā)生在2025-04-19 13:39:45分。再根據(jù)我們的業(yè)務(wù)日志，即可確定本次死鎖的日志內(nèi)容。

（2）確定死鎖發(fā)生的順序

在上面的例子中，發(fā)生死鎖的兩個事務(wù)分別是10047號事務(wù) (1) TRANSACTION。

*** (1) TRANSACTION:
TRANSACTION 10047, ACTIVE 10 sec starting index read

發(fā)生死鎖時， (1) TRANSACTION已經(jīng)進(jìn)行了10秒的索引查詢動作。

以及10048號事務(wù)(2) TRANSACTION

*** (2) TRANSACTION:
TRANSACTION 10048, ACTIVE 21 sec starting index read

發(fā)生死鎖時，(2) TRANSACTION已經(jīng)進(jìn)行了21秒的索引查詢動作。

我們知道，事務(wù)ID是順序增加的，更大的事務(wù)ID意味著更晚分配事務(wù)ID。

那么有的同學(xué)就有疑問了，為什么 (2) TRANSACTION后于 (1) TRANSACTION創(chuàng)建，線程的執(zhí)行時間卻更長呢。

那是因?yàn)椋瑢τ谧x寫事務(wù)來說，只有在它第一次對某個表執(zhí)行增刪改操作時，才會為這個事務(wù)分配一個事務(wù)id，否則是不分配事務(wù) id 的。 有時，雖然我們開啟了一個讀寫事務(wù)，但是這個事務(wù)中全是查詢語句，并沒有執(zhí)行增刪改操作的語句，這也就意味著這個事務(wù)并不會被分配一個事務(wù)id。 因此，雖然有時運(yùn)行的時間長，反而后分配了事務(wù)ID。

基于事務(wù)ID的大小，我們可以確定， (2) TRANSACTION后于 (1) TRANSACTION:分配事務(wù)ID，但是(2) TRANSACTION更早運(yùn)行。

（3）確定死鎖發(fā)生的位置以及觸發(fā)的SQL內(nèi)容

我們現(xiàn)在回到死鎖日志。

MySQL thread id 8, OS thread handle 13013229568, query id 113 localhost root updating
DELETE FROM t1 WHERE i = 1

這兩行提示了死鎖發(fā)生時當(dāng)前事務(wù)執(zhí)行的sql內(nèi)容。

死鎖發(fā)生時正在執(zhí)行一條delete語句。

接著往下看。

*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 44 page no 3 n bits 72 index PRIMARY of table `itsuka`.`t1` trx id 10047 lock_mode X locks rec but not gap waiting

這里展示了死鎖發(fā)生時等待的鎖的位置與內(nèi)容 本次死鎖發(fā)生在PRIMARY即主鍵索引行，死鎖的表為‘itsuka’庫的‘t1’表，并且正在等待一個‘lock_mode X locks rec but not gap waiting’鎖。

那么‘lock_mode X locks rec but not gap waiting’鎖是一個什么東西呢？

數(shù)據(jù)庫中鎖的類型大家都很熟悉，這里就不做介紹。只給出日志中各種鎖對應(yīng)的關(guān)鍵字：

基于此，我們可以確定，死鎖發(fā)生時，10047號事務(wù) (1) TRANSACTION，正在等待一個主鍵索引上的排他記錄鎖

那么等待的鎖的具體內(nèi)容是什么呢，或者說，他正在等待誰呢，我們接著往下看

Record lock, heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 0: len 4; hex 80000001; asc     ;;
 1: len 6; hex 00000000273e; asc     '>;;
 2: len 7; hex ad000001210110; asc     !  ;;

這一段，表示等待的鎖的具體信息，包括一些行的物理存儲位置信息。

• 針對主鍵索引來著，這里保存的內(nèi)容是

對應(yīng)到上面的案例只有0、1、2的原因是，我的測試表的結(jié)構(gòu)為

CREATE TABLE `t1`(
    `i` int(11) NOT NULL,
    PRIMARY KEY (`i`)
) ENGINE = InnoDB

因?yàn)橹挥兄麈I列，自然就沒有后續(xù)的其他內(nèi)容。對于更加復(fù)雜的表，我們也許會看到類似如下的信息：

image

原理是一樣的，事務(wù)ID 和 回滾段指針 列不需要過多關(guān)注，這里不展開說明。

那么，我們?nèi)绾伟哑渲袑?yīng)的數(shù)值解析出來呢。

針對有符號數(shù)值型存儲，MySQL為了確保正數(shù)的數(shù)值一定大于負(fù)數(shù)，因此會將每一個數(shù)值拆成單個字節(jié)，再對最高位字節(jié)（最高的8個二進(jìn)制位）的最高位與128（1000,0000）進(jìn)行異或操作，相當(dāng)于將正數(shù)和負(fù)數(shù)的符號位反過來。

我們找一條相對復(fù)雜的日志為例

0: len 8; hex 85558556e13000e1; asc  U V 0  ;;

將16進(jìn)制值85558556e13000e1貼入計(jì)算器

image

可以觀察到最高位二進(jìn)制數(shù)字為1，說明在進(jìn)行異或計(jì)算前這一位為0，我們將其高位修改為0。

image

于是我們得到16進(jìn)制數(shù)字0x5558556E13000E1，再將其轉(zhuǎn)為10進(jìn)制。

image

這樣一來我們就解析到了得到真正存儲的數(shù)據(jù)：384359951401746657。

如法炮制，我們同樣得到本次案例中的主鍵數(shù)據(jù)

0: len 4; hex 80000001; asc     ;;

解析后得到1。即，鎖加在了主鍵為1的這一條記錄上。

如果是字符類型，只需要按照對應(yīng)的字符集切分成相同大小的字節(jié)塊，每個字節(jié)塊單獨(dú)映射即可。

通常針對字符類型的反算就是deepseek出場的時候了，但是數(shù)值類型還是我們手動來比較好，deepseek似乎算不太明白。

上面重點(diǎn)講述了主鍵索引在死鎖日志中的日志結(jié)構(gòu)，二級索引結(jié)構(gòu)很類似。

• 針對二級索引來說，這里保存的內(nèi)容是

現(xiàn)在回到案例上來，我們現(xiàn)在已經(jīng)確定了，事務(wù)1的死鎖發(fā)生在‘itsuka’庫的‘t1’表的主鍵索引上，死鎖發(fā)生時正在等待自己的排他記錄鎖的獲取，鎖的位置位于主鍵索引上主鍵為1（80000001）那條記錄

事務(wù)2的死鎖日志大部分與事務(wù)1相同，只是多了如下內(nèi)容

*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 44 page no 3 n bits 72 index PRIMARY of table `itsuka`.`t1` trx id 10048 lock mode S locks rec but not gap
Record lock, heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 0: len 4; hex 80000001; asc     ;;
 1: len 6; hex 00000000273e; asc     '>;;
 2: len 7; hex ad000001210110; asc     !  ;;

這段表明，死鎖發(fā)生時，事務(wù)2已經(jīng)持有一把鎖，鎖的類型是共享記錄鎖，鎖的位置為主鍵索引上主鍵為1

（ 0: len 4; hex 80000001; asc     ;;）

的那條記錄。

同時，事務(wù)2的死鎖發(fā)生時還在等待自己的排他記錄鎖的獲取，鎖的位置位于主鍵索引上主鍵為1

（ 0: len 4; hex 80000001; asc     ;;）

的那條記錄

至此，我們的死鎖日志就分析就全部結(jié)束了。

3、確定死鎖原因

基于上一節(jié)我們知道了，死鎖發(fā)生時我們收集到了兩個事務(wù)的信息。

事務(wù)1的事物ID為10047，事務(wù)執(zhí)行的時間較短為10秒鐘，死鎖時正在等待獲取一把獨(dú)占型記錄鎖，這把鎖加在了‘itsuka’庫的‘t1’表的主鍵索引上主鍵為1的那條記錄上。

事務(wù)2的事物ID為10048，事務(wù)執(zhí)行的時間較長為21秒鐘，死鎖時正持有一把共享型記錄鎖，這把鎖加在了‘itsuka’庫的‘t1’表的主鍵索引上主鍵為1的那條記錄上，同時事務(wù)2又嘗試獲取一把獨(dú)占型記錄鎖，這把鎖加在了‘itsuka’庫的‘t1’表的主鍵索引上主鍵為1的那條記錄上。

在開始我們下一階段的思考之前，我們需要明確幾個問題。

（1）InnoDB順序加鎖順序解鎖（公平鎖）

image

基于MySQL的官方文檔，我們可以知道。一個事務(wù)成功加鎖的前提是：這條記錄的鎖等待隊(duì)列中，當(dāng)前事務(wù)前面所有不兼容的加鎖請求都已釋放（提交或回滾）

（2）死鎖日志中出現(xiàn)的鎖，不論是等待的鎖，還是持有的，都是每個事務(wù)已經(jīng)擁有的鎖結(jié)構(gòu)

有別于java中的鎖，例如ReentrantLock。不管有幾個線程來爭搶這把鎖，自始至終都只有一個鎖結(jié)構(gòu)，拿到鎖的線程擁有這把鎖，沒拿到鎖的線程不擁有這把鎖。

而MySQL每次加鎖都會在內(nèi)存中生成一個獨(dú)屬于這個事務(wù)的鎖結(jié)構(gòu)，只不過鎖結(jié)構(gòu)里有一個等待狀態(tài)的標(biāo)志，表示這個鎖獲取成功還是失敗。

在進(jìn)行MySQL的加鎖分析時，一定要明白，不論當(dāng)前事務(wù)有沒有成功獲取到鎖，都已經(jīng)建立了鎖結(jié)構(gòu)。

因此，上述案例中的鎖結(jié)構(gòu)示意圖如下所示。

image

接下來我們要做的就是逐個分析鎖結(jié)構(gòu)，判斷他的來源以及為什么沒能成功獲取。

所以，該案例的死鎖原因就找到了:

T2事務(wù)先獲取了了S型記錄鎖，T1事務(wù)再嘗試獲取X型記錄鎖，與S型記錄鎖沖突，因此T1事務(wù)陷入等待。此時T2事務(wù)再嘗試獲取這條記錄的X型記錄鎖，根據(jù)請求鎖的原則：這條記錄的鎖等待隊(duì)列中，與T2事務(wù)的加鎖請求沖突的鎖都已釋放（提交或回滾），T2事務(wù)才能加鎖成功。因此T2事務(wù)也陷入等待，并且T2事務(wù)需要等待T1事務(wù)先獲取鎖，但T1事務(wù)要等待T2事務(wù)的S型記錄鎖釋放，死鎖因此產(chǎn)生。

再結(jié)合我們的sql，我們就可以完整還原現(xiàn)場：

4、拓展：特殊情況加鎖引起的死鎖

當(dāng)然，很多時候死鎖的產(chǎn)生并不完全是由兩條 SQL 顯式加鎖導(dǎo)致的。MySQL 可能會背著我們偷偷的加一些鎖，從而引發(fā)死鎖。但是不論是如何加鎖，我們都要先找到死鎖發(fā)生時，每個事務(wù)都涉及到了哪些鎖結(jié)構(gòu)，這些鎖加在了哪里。然后再逐個分析，或者說‘猜’，這些鎖是如何產(chǎn)生的。

例如，當(dāng)MySQL在插入或者更新記錄時出現(xiàn)唯一鍵沖突，那么會對重復(fù)的key加S類型的next-key鎖。因?yàn)閷τ?nbsp;MySQL 來說，不能直接報(bào)錯，要先檢查當(dāng)前沖突記錄是否為有效記錄，如果發(fā)現(xiàn)沖突的記錄被標(biāo)記刪除了，說明他不是有效記錄，新紀(jì)錄可以插入，否則要報(bào)錯。為了防止其它事務(wù)更新或者刪除這條記錄、或者往這條記錄前面的間隙里插入記錄，開始檢查工作之前，MySQL 會對這條記錄加共享鎖。

而當(dāng)insert 語句帶上on duplicate key update這個小尾巴時，這個小尾巴的作用是發(fā)現(xiàn)沖突記錄時執(zhí)行更新操作，既然是更新操作則需要加排他鎖，所以這種情況下發(fā)生唯一鍵沖突，就直接加排他鎖。

更多加鎖情況這里不展開講，大家可以自行查閱官方文檔，針對每種加鎖場景都有明確的描述：https://dev.mysql.com/doc/refman/5.7/en/innodb-locks-set.html

關(guān)于作者

黃敬乾   俠客匯Java開發(fā)工程師