溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
前言
死鎖的本質是資源競爭，批量插入如果順序不一致很容易導致死鎖，我們來分析一下這個情況。為了方便演示，把批量插入改寫為了多條 insert。
先來做幾個小實驗，簡化的表結構如下
CREATE TABLE `t1` ( `id` int(11) NOT NULL AUTO_INCREMENT, `a` varchar(5), `b` varchar(5), PRIMARY KEY (`id`), UNIQUE KEY `uk_name` (`a`,`b`) );
實驗1：
在記錄不存在的情況下，兩個同樣順序的批量 insert 同時執行，第二個會進行鎖等待狀態
| t1 | t2 | |
|---|---|---|
| begin; | begin; | |
| insert ignore into t1(a, b)values("1", "1"); | 成功 | |
| insert ignore into t1(a, b)values("1", "1"); | 鎖等待狀態 |
可以看到目前鎖的狀態
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' | +-------------+-------------+-----------+-----------+------------+------------+------------+-----------+----------+-----------+
在我們執行事務t1的 insert 時，沒有在任何鎖的斷點處出現，這跟 MySQL 插入的原理有關系
insert 加的是隱式鎖。什么是隱式鎖？隱式鎖的意思就是沒有鎖
在 t1 插入記錄時，是不加鎖的。這個時候事務 t1 還未提交的情況下，事務 t2 嘗試插入的時候，發現有這條記錄，t2 嘗試獲取 S 鎖，會判定記錄上的事務 id 是否活躍，如果活躍的話，說明事務未結束，會幫 t1 把它的隱式鎖提升為顯式鎖（ X 鎖）
源碼如下
t2 獲取S鎖的結果:DB_LOCK_WAIT
實驗2：
批量插入順序不一致的導致的死鎖
| 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 鎖，進入 DB_LOCK_WAIT | |
| insert into t1(a, b)values("1", "1"); | t2 嘗試獲取 S 鎖，把 t1 的隱式鎖提升為顯式 X 鎖，產生死鎖 |
------------------------
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)
怎么樣解決這樣的問題呢？
一個可行的辦法是在應用層排序以后再插入
總結
以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，謝謝大家對億速云的支持。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
