共計 2920 個字符，預計需要花費 8 分鐘才能閱讀完成。
本篇內容介紹了“mysql insert 導致死鎖的案例介紹”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓丸趣 TV 小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！
兩個 insert 語句發生死鎖的案例。
一. 準備數據
CREATE TABLE `t1` (`a` int(11) NOT NULL,
PRIMARY KEY (`a`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
insert into t1 values(1);
mysql insert into t1 values(1);
Query OK, 1 row affected (0.20 sec)
mysql select * from t1;
+---+
| a |
+---+
| 1 |
+---+
1 row in set (0.00 sec)二. 發起如下事務
會話 1
會話 2
會話 3
begin;
delete from t1 where a=1;
begin;
insert into t1 select 1;
begin;
insert into t1 select 1;
Commit
ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction
簡單理解下，刪除數據的會話持有 X 鎖，導致兩條 insert 語句需要等待，這沒問題，
但是為什么刪除提交后，兩個競爭關系出現了死鎖。
show engine innodb status 部分結果：
------------------------
LATEST DETECTED DEADLOCK
------------------------
2020-05-17 13:50:24 0x7f660c3f0700
*** (1) TRANSACTION:
TRANSACTION 4377, ACTIVE 13 sec inserting
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 1136, 2 row lock(s)
MySQL thread id 3, OS thread handle 140076399294208, query id 59 localhost root executing
insert into t1 select 1
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 99 page no 3 n bits 72 index PRIMARY of table `ming`.`t1` trx id 4377 lock_mode X locks rec but not gap waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 32
0: len 4; hex 80000001; asc ;;
1: len 6; hex 000000001114; asc ;;
2: len 7; hex 3400000144129f; asc 4 D ;;
*** (2) TRANSACTION:
TRANSACTION 4378, ACTIVE 10 sec inserting, thread declared inside InnoDB 1
mysql tables in use 1, locked 1
3 lock struct(s), heap size 1136, 2 row lock(s)
MySQL thread id 4, OS thread handle 140076268848896, query id 61 localhost root executing
insert into t1 select 1
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 99 page no 3 n bits 72 index PRIMARY of table `ming`.`t1` trx id 4378 lock mode S
Record lock, heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 32
0: len 4; hex 80000001; asc ;;
1: len 6; hex 000000001114; asc ;;
2: len 7; hex 3400000144129f; asc 4 D ;;
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 99 page no 3 n bits 72 index PRIMARY of table `ming`.`t1` trx id 4378 lock_mode X locks rec but not gap waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 32
0: len 4; hex 80000001; asc ;;
1: len 6; hex 000000001114; asc ;;
2: len 7; hex 3400000144129f; asc 4 D ;;
*** WE ROLL BACK TRANSACTION (2)可以看到會話 2 正在等待一個 X 行鎖，會話 3 也在等待 X 行鎖，但是同時持有一個 S 鎖。
這個 S 鎖是怎么來的呢？
當進行唯一性沖突檢測時，需要先加一個 S 鎖。
那么整個過程就是如下所示
會話 1
會話 2
會話 3
begin;
delete from t1 where a=1;
持有 a = 1 就的 X 行鎖
begin;
insert into t1 select 1;
為了判斷唯一性，請求 a = 1 的 next-key lock S 鎖被阻塞，等待
begin;
insert into t1 select 1;
為了判斷唯一性，請求 a = 1 的 next-key lock S 鎖被阻塞，等待
Commit
釋放 a = 1 上的鎖
拿到 a = 1 的 next-key lock S 鎖，繼續嘗試拿 a = 1 的 X 行鎖，但是被會話 3 的 S 鎖阻塞
拿到 a = 1 的 next-key lock S 鎖，繼續嘗試拿 a = 1 的 X 行鎖，嘗試拿到 a = 1 的 X 行鎖，但是被會話 2 的 S 鎖阻塞。
觸發死鎖
ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction
“mysql insert 導致死鎖的案例介紹”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注丸趣 TV 網站，丸趣 TV 小編將為大家輸出更多高質量的實用文章！
