MySQL 死鎖套路：一次詭異的批量插入死鎖問(wèn)題分析

afishhhhh 發(fā)布于2019-05-27 17:42 / 866人閱讀

摘要：線上最近出現(xiàn)了批量的死鎖，百思不得姐。死鎖記錄如下第一反應(yīng)是批量，的順序不一樣導(dǎo)致的死鎖。什么是隱式鎖隱式鎖的意思就是沒(méi)有鎖在插入記錄時(shí)，是不加鎖的。

線上最近出現(xiàn)了批量insert的死鎖，百思不得姐。死鎖記錄如下

2018-10-26T11:04:41.759589Z 8530809 [Note] InnoDB: 
*** (1) TRANSACTION:

TRANSACTION 1202026765, ACTIVE 0 sec inserting
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 1136, 3 row lock(s), undo log entries 1
MySQL thread id 8532863, OS thread handle 139858337453824, query id 16231472122 10.111.10.143 seewo update
INSERT IGNORE INTO xx_performance_type_label_relation(label_id, performance_type_id, type, create_time)
    VALUES
      
      ("bb0394e670644168a998a93a3ed521bc", "06b96ee0bab84d71bb17bf9645d3aa54", 1, now())
     , 
      ("bb0394e670644168a998a93a3ed521bc", "27d82e2331b241e1a9c9c0a74ec21099", -1, now())
     , 
      ("bb0394e670644168a998a93a3ed521bc", "3100b5978fb24f56b327d25732a7d7a7", 1, now())
     , 
      ("bb0394e670644168a998a93a3ed521bc", "435a1e19ce6e4e5bbb84240b3b34cf03", 1, now())
     , 
      ("bb0394e670644168a998a93a3ed521bc", "447fe27199ca40e289ef2834469d9a78", 1, now())
     , 
      ("bb0394e670644168a998a93a3ed521bc", "87a52c4d00844b5bb9eb75e8fe34202a", 1, now())
     , 
      ("bb0394e670644168a998a93a3ed521bc", "c6a0e26983bd4fae837d5ee2f4efeef8", 1, now())
2018-10-26T11:04:41.759635Z 8530809 [Note] InnoDB: *** (1) WAITING FOR THIS LOCK TO BE GRANTED:

RECORD LOCKS space id 505 page no 9912 n bits 288 index uk_performance_type_id_label_id of table `masaike`.`xx_performance_type_label_relation` trx id 1202026765 lock_mode X locks gap before rec insert intention waiting
2018-10-26T11:04:41.759674Z 8530809 [Note] InnoDB: *** (2) TRANSACTION:

TRANSACTION 1202026764, ACTIVE 0 sec inserting
mysql tables in use 1, locked 1
3 lock struct(s), heap size 1136, 3 row lock(s), undo log entries 1
MySQL thread id 8530809, OS thread handle 139858469242624, query id 16231472119 10.111.10.153 seewo update
INSERT IGNORE INTO xx_performance_type_label_relation(label_id, performance_type_id, type, create_time)
    VALUES
      
      ("bb0394e670644168a998a93a3ed521bc", "06b96ee0bab84d71bb17bf9645d3aa54", 1, now())
     , 
      ("bb0394e670644168a998a93a3ed521bc", "27d82e2331b241e1a9c9c0a74ec21099", -1, now())
     , 
      ("bb0394e670644168a998a93a3ed521bc", "3100b5978fb24f56b327d25732a7d7a7", 1, now())
     , 
      ("bb0394e670644168a998a93a3ed521bc", "435a1e19ce6e4e5bbb84240b3b34cf03", 1, now())
     , 
      ("bb0394e670644168a998a93a3ed521bc", "447fe27199ca40e289ef2834469d9a78", 1, now())
     , 
      ("bb0394e670644168a998a93a3ed521bc", "87a52c4d00844b5bb9eb75e8fe34202a", 1, now())
     , 
      ("bb0394e670644168a998a93a3ed521bc", "c6a0e26983bd4fae837d5ee2f4efeef8", 1, now())
2018-10-26T11:04:41.759713Z 8530809 [Note] InnoDB: *** (2) HOLDS THE LOCK(S):

RECORD LOCKS space id 505 page no 9912 n bits 288 index uk_performance_type_id_label_id of table `masaike`.`xx_performance_type_label_relation` trx id 1202026764 lock mode S
2018-10-26T11:04:41.759753Z 8530809 [Note] InnoDB: *** (2) WAITING FOR THIS LOCK TO BE GRANTED:

RECORD LOCKS space id 505 page no 9912 n bits 288 index uk_performance_type_id_label_id of table `masaike`.`xx_performance_type_label_relation` trx id 1202026764 lock_mode X locks gap before rec insert intention waiting
2018-10-26T11:04:41.759784Z 8530809 [Note] InnoDB: *** WE ROLL BACK TRANSACTION (2)

第一反應(yīng)是批量insert，insert的順序不一樣導(dǎo)致的死鎖。但是這個(gè)在這里是不成立的。原因有兩點(diǎn)

出現(xiàn)問(wèn)題的批量插入SQL中順序是一模一樣的，在順序一樣的情況下，只會(huì)進(jìn)行插入等待（implicit lock轉(zhuǎn)explicit X鎖）下面有實(shí)驗(yàn)

如果是因?yàn)榕坎迦腠樞虿灰恢聨?lái)的死鎖日志，打印的結(jié)果不是等待插入意向鎖（insert intention waiting），下面有實(shí)驗(yàn)

現(xiàn)在采用一個(gè)簡(jiǎn)化的表，做實(shí)驗(yàn)

CREATE TABLE `t1` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `a` varchar(5)  NOT NULL DEFAULT "",
  `b` varchar(5)  NOT NULL DEFAULT "",
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_name` (`a`,`b`)
) ENGINE=InnoDB;

實(shí)驗(yàn) 01

在記錄不存在的情況下，兩個(gè)同樣順序的批量insert同時(shí)執(zhí)行，第二個(gè)會(huì)進(jìn)行鎖等待狀態(tài)

首先truncate t1;

t1	t2
begin;	begin;
insert ignore into t1(a, b)values("1", "1");		成功
	insert ignore into t1(a, b)values("1", "1");	鎖等待狀態(tài)

可以看到目前鎖的狀態(tài)

mysql> select * from information_schema.innodb_locks;
+-------------+-------------+-----------+-----------+------------+------------+------------+-----------+----------+-----------+
| lock_id     | lock_trx_id | lock_mode | lock_type | lock_table | lock_index | lock_space | lock_page | lock_rec | lock_data |
+-------------+-------------+-----------+-----------+------------+------------+------------+-----------+----------+-----------+
| 31AE:54:4:2 | 31AE        | S         | RECORD    | `d1`.`t1`  | `uk_name`  |         54 |         4 |        2 | "1", "1"  |
| 31AD:54:4:2 | 31AD        | X         | RECORD    | `d1`.`t1`  | `uk_name`  |         54 |         4 |        2 | "1", "1"  |
+-------------+-------------+-----------+-----------+------------+------------+------------+-----------+----------+-----------+

在我們執(zhí)行事務(wù)t1的insert時(shí)，沒(méi)有在任何鎖的斷點(diǎn)處出現(xiàn)，這跟MySQL插入的原理有關(guān)系

insert 加的是隱式鎖。什么是隱式鎖？隱式鎖的意思就是沒(méi)有鎖

在t1插入記錄時(shí)，是不加鎖的。這個(gè)時(shí)候事務(wù)t1還未提交的情況下，事務(wù)t2嘗試插入的時(shí)候，發(fā)現(xiàn)有這條記錄，t2嘗試獲取S鎖，會(huì)判定記錄上的事務(wù)id是否活躍，如果活躍的話，說(shuō)明事務(wù)未結(jié)束，會(huì)幫t1把它的隱式鎖提升為顯式鎖（X鎖）

源碼如下

t2獲取S鎖的結(jié)果:DB_LOCK_WAIT

實(shí)驗(yàn)02

批量插入順序不一致的導(dǎo)致的死鎖日志不是等待插入意向鎖

t1	t2
begin
insert into t1(a, b)values("1", "1");		成功
	insert into t1(a, b)values("2", "2");	成功
insert into t1(a, b)values("2", "2");		t1嘗試獲取S鎖，把t2的隱式鎖提升為顯式X鎖，進(jìn)入DB_LOCK_WAIT
	insert into t1(a, b)values("1", "1");	t2嘗試獲取S鎖，把t1的隱式鎖提升為顯式X鎖，產(chǎn)生死鎖

------------------------
LATEST DETECTED DEADLOCK
------------------------
181101  9:48:36
*** (1) TRANSACTION:
TRANSACTION 3309, ACTIVE 215 sec inserting
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 376, 2 row lock(s), undo log entries 2
MySQL thread id 2, OS thread handle 0x70000a845000, query id 58 localhost root update
insert into t1(a, b)values("2", "2")
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 55 page no 4 n bits 72 index `uk_name` of table `d1`.`t1` trx id 3309 lock mode S waiting
Record lock, heap no 3 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 0: len 1; hex 32; asc 2;;
 1: len 1; hex 32; asc 2;;
 2: len 4; hex 80000002; asc     ;;

*** (2) TRANSACTION:
TRANSACTION 330A, ACTIVE 163 sec inserting
mysql tables in use 1, locked 1
3 lock struct(s), heap size 376, 2 row lock(s), undo log entries 2
MySQL thread id 3, OS thread handle 0x70000a888000, query id 59 localhost root update
insert into t1(a, b)values("1", "1")
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 55 page no 4 n bits 72 index `uk_name` of table `d1`.`t1` trx id 330A lock_mode X locks rec but not gap
Record lock, heap no 3 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 0: len 1; hex 32; asc 2;;
 1: len 1; hex 32; asc 2;;
 2: len 4; hex 80000002; asc     ;;

*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 55 page no 4 n bits 72 index `uk_name` of table `d1`.`t1` trx id 330A lock mode S waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 0: len 1; hex 31; asc 1;;
 1: len 1; hex 31; asc 1;;
 2: len 4; hex 80000001; asc     ;;

*** WE ROLL BACK TRANSACTION (2)

到目前為止，已經(jīng)陷入了僵局，完全沒(méi)法復(fù)現(xiàn)死鎖的情況。看了代碼，發(fā)現(xiàn)在insert之前有一個(gè)delete，但是delete與insert不在一個(gè)事務(wù)里面，也就是delete提交以后，才進(jìn)行批量insert，真正出問(wèn)題的地方在批量insert的地方。一開(kāi)始就排除了delete對(duì)后面的影響，難道不在一個(gè)事務(wù)，也會(huì)有影響？

寫(xiě)了一個(gè)代碼去模擬，有很大概率會(huì)復(fù)現(xiàn)

fun test() {
    dao.delete() // 對(duì)應(yīng)delete from
    // sleep for 10ms
    dao.insert() // 對(duì)應(yīng)insert ignore
}

對(duì)應(yīng)的 SQL 如下，注意是兩個(gè)事務(wù)

begin;
delete from t1 where a = "25"
commit;

begin;
INSERT ignore INTO `t1` (`a`, `b`) VALUES("25","1")
commit;

這個(gè)代碼在兩個(gè)線程同時(shí)調(diào)用的時(shí)候，非常容易死鎖。

后來(lái)翻遍了網(wǎng)上相關(guān)的死鎖案例，有一個(gè)關(guān)于purge刪除的過(guò)程可能跟這個(gè)有關(guān)系。

如果標(biāo)記為刪除，說(shuō)明事務(wù)已經(jīng)提交，還沒(méi)來(lái)得及 purge，這時(shí)后面的事務(wù)加S鎖等待；

在源碼中打印一些日志。 1.在storage/innobase/row/row0ins.c的row_ins_set_shared_rec_lock增加日志，可以看到對(duì)唯一索引增加S鎖的過(guò)程

if (dict_index_is_clust(index)) {
    err = lock_clust_rec_read_check_and_lock(
        0, block, rec, index, offsets, LOCK_S, type, thr);
} else {
    err = lock_sec_rec_read_check_and_lock(
        0, block, rec, index, offsets, LOCK_S, type, thr);
    // 增加如下日志
    fprintf(stderr, "row_ins_set_shared_rec_lock %s %lu %d
" , index->name, type, err);
}

2.在lock_rec_enqueue_waiting增加日志，可以看到鎖等待的情況

static
enum db_err
lock_rec_enqueue_waiting(
{
	fprintf(stderr, "lock_rec_enqueue_waiting::::: %s %lu
" , index->name, type_mode);
}

日志大概如下

row_ins_set_shared_rec_lock uk_name 0 9 (t1獲取S鎖成功）
row_ins_set_shared_rec_lock uk_name 0 9 (t2獲取S鎖成功）

lock_rec_enqueue_waiting::::: uk_name 2563（t1 X鎖進(jìn)如鎖等待）
lock_rec_enqueue_waiting::::: uk_name 2563（t2 X鎖進(jìn)如鎖等待）

其中2563=2048+512+3=LOCK_INSERT_INTENTION+LOCK_GAP+LOCK_X

這個(gè)過(guò)程跟非常經(jīng)典的三個(gè)事務(wù)同時(shí)insert，一個(gè)回滾，剩下的兩個(gè)事務(wù)一個(gè)成功，一個(gè)死鎖，其實(shí)是一模一樣的原理。

實(shí)驗(yàn)03

三個(gè) insert ignore，一個(gè)回滾造成的死鎖

insert語(yǔ)句都是insert ignore into t1(a, b)values("1", "1");以下省略

t1	t2	t3	備注
begin	begin	begin
insert			成功
	insert		把t1的隱式鎖提升為X鎖，t2進(jìn)入進(jìn)入S鎖等待
		insert	t3進(jìn)入進(jìn)入S鎖等待
rollback;			t1回滾以后，釋放X鎖，t2和t3同時(shí)拿到了S鎖
	ok	deadlock	t2和t3都想拿插入意向鎖X鎖，造成死鎖條件

死鎖日志，跟我們案例中的一模一樣

------------------------
LATEST DETECTED DEADLOCK
------------------------
181101 23:22:59
*** (1) TRANSACTION:
TRANSACTION 5032, ACTIVE 11 sec inserting
mysql tables in use 1, locked 1
LOCK WAIT 4 lock struct(s), heap size 1248, 2 row lock(s), undo log entries 1
MySQL thread id 5, OS thread handle 0x70000d736000, query id 125 localhost root update
insert ignore into t1(a, b)values("1", "1")
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 56 page no 4 n bits 584 index `uk_name` of table `d1`.`t1` trx id 5032 lock_mode X locks gap before rec insert intention waiting
Record lock, heap no 139 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 0: len 3; hex 313031; asc 101;;
 1: len 3; hex 313031; asc 101;;
 2: len 4; hex 800007b1; asc     ;;

*** (2) TRANSACTION:
TRANSACTION 5033, ACTIVE 6 sec inserting
mysql tables in use 1, locked 1
4 lock struct(s), heap size 1248, 2 row lock(s), undo log entries 1
MySQL thread id 6, OS thread handle 0x70000d779000, query id 126 localhost root update
insert ignore into t1(a, b)values("1", "1")
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 56 page no 4 n bits 584 index `uk_name` of table `d1`.`t1` trx id 5033 lock mode S locks gap before rec
Record lock, heap no 139 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 0: len 3; hex 313031; asc 101;;
 1: len 3; hex 313031; asc 101;;
 2: len 4; hex 800007b1; asc     ;;

*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 56 page no 4 n bits 584 index `uk_name` of table `d1`.`t1` trx id 5033 lock_mode X locks gap before rec insert intention waiting
Record lock, heap no 139 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 0: len 3; hex 313031; asc 101;;
 1: len 3; hex 313031; asc 101;;
 2: len 4; hex 800007b1; asc     ;;

*** WE ROLL BACK TRANSACTION (2)

目前來(lái)看，得到的結(jié)論是：

一個(gè)已提交但是未purge掉的記錄會(huì)造成后續(xù)插入獲取S共享鎖，兩個(gè)事務(wù)同時(shí)獲取S鎖，然后嘗試獲取插入意向鎖，造成死鎖

網(wǎng)上大神梳理的insert流程

首先對(duì)插入的間隙加插入意向鎖（Insert Intension Locks）

如果該間隙已被加上了 GAP 鎖或 Next-Key 鎖，則加鎖失敗進(jìn)入等待；

如果沒(méi)有，則加鎖成功，表示可以插入；

然后判斷插入記錄是否有唯一鍵，如果有，則進(jìn)行唯一性約束檢查

如果不存在相同鍵值，則完成插入

如果存在相同鍵值，則判斷該鍵值是否加鎖

如果沒(méi)有鎖，判斷該記錄是否被標(biāo)記為刪除

如果標(biāo)記為刪除，說(shuō)明事務(wù)已經(jīng)提交，還沒(méi)來(lái)得及 purge，這時(shí)加 S 鎖等待；

如果沒(méi)有標(biāo)記刪除，則報(bào) 1062 duplicate key 錯(cuò)誤；

如果有鎖，說(shuō)明該記錄正在處理（新增、刪除或更新），且事務(wù)還未提交，加 S 鎖等待；

插入記錄并對(duì)記錄加 X 記錄鎖；

上面是我 debug 源碼得到的一些結(jié)論，如果我的理解有誤的話，記得留言告訴我

以下為參考文檔

www.aneasystone.com/archives/20…

hedengcheng.com/");

GPU云服務(wù)器云服務(wù)器 MySQL死鎖 MySQL 死鎖死鎖分析 mysql 死鎖監(jiān)控

文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請(qǐng)注明本文地址：http://www.ezyhdfw.cn/yun/7869.html

發(fā)表評(píng)論

登陸后可評(píng)論

0條評(píng)論

afishhhhh

男|高級(jí)講師

我要關(guān)注我要私信

TA的文章

tensorflow如何安裝

閱讀 2929·2023-04-25 17:59
tensorflow對(duì)應(yīng)keras版本

閱讀 759·2023-04-25 15:05
第七章-內(nèi)部類#yyds干貨盤(pán)點(diǎn)#

閱讀 726·2021-11-25 09:43
ESLint v8.0.0 發(fā)布、React 成立 Developer Tooling 團(tuán)隊(duì) | 淘

閱讀 3107·2021-10-12 10:13
FastComet：日本主機(jī)/美國(guó)等全球10大數(shù)據(jù)中心cPanel共享主機(jī)/外貿(mào)主機(jī)年付低至35刀，

閱讀 3611·2021-09-27 13:59
P5 005本地環(huán)境及開(kāi)發(fā)工具

閱讀 3636·2021-09-23 11:21
17.WLAN拓?fù)浣榻B_無(wú)線分布式系統(tǒng)

閱讀 3966·2021-09-08 09:35
突破css選擇器的局限，實(shí)現(xiàn)一個(gè)css地址選擇器?

閱讀 637·2019-08-29 17:12

亚洲中字慕日产2020,大陆极品少妇内射AAAAAA,无码av大香线蕉伊人久久,久久精品国产亚洲av麻豆网站

資訊專欄INFORMATION COLUMN

上云采購(gòu)季！| 2核2G4M爆款云服務(wù)器低至59元/年，更有多臺(tái)、長(zhǎng)期優(yōu)惠，快來(lái)選購(gòu)！

MySQL 死鎖套路：一次詭異的批量插入死鎖問(wèn)題分析

相關(guān)文章

MySQL 死鎖套路：唯一索引下批量插入順序不一致

為什么開(kāi)發(fā)人員必須要了解數(shù)據(jù)庫(kù)鎖？

發(fā)表評(píng)論

0條評(píng)論

afishhhhh

男|高級(jí)講師

TA的文章

tensorflow如何安裝

tensorflow對(duì)應(yīng)keras版本

第七章-內(nèi)部類#yyds干貨盤(pán)點(diǎn)#

ESLint v8.0.0 發(fā)布、React 成立 Developer Tooling 團(tuán)隊(duì) | 淘

FastComet：日本主機(jī)/美國(guó)等全球10大數(shù)據(jù)中心cPanel共享主機(jī)/外貿(mào)主機(jī)年付低至35刀，

P5 005本地環(huán)境及開(kāi)發(fā)工具

17.WLAN拓?fù)浣榻B_無(wú)線分布式系統(tǒng)

突破css選擇器的局限，實(shí)現(xiàn)一個(gè)css地址選擇器?

最新活動(dòng)

資訊專欄INFORMATION COLUMN

上云采購(gòu)季！| 2核2G4M爆款云服務(wù)器低至59元/年，更有多臺(tái)、長(zhǎng)期優(yōu)惠，快來(lái)選購(gòu)！

MySQL 死鎖套路：一次詭異的批量插入死鎖問(wèn)題分析

相關(guān)文章

發(fā)表評(píng)論

0條評(píng)論

男|高級(jí)講師

TA的文章

最新活動(dòng)

上云采購(gòu)季！| 2核2G4M爆款云服務(wù)器低至59元/年，更有多臺(tái)、長(zhǎng)期優(yōu)惠，快來(lái)選購(gòu)！