聊聊MySQL中的死鎖
死鎖是指兩個或者多個事務互相持有對方所需的資源，從而導致它們都無法繼續執行的情況。下圖是一個死鎖的示例，事務1鎖住了id=1的數據（比如更新id=1的數據記錄），同時請求鎖住id=2的數據，但事務2持有id=2的鎖，同時又請求id=1的鎖，這樣就造成了相互等待對方釋放鎖的情況，從而產生了死鎖：
圖片
上圖是死鎖產生的示例說明，我們用實際的SQL來演示死鎖的產生，首先創建一個測試表，它只有兩個字段，id和數量，id為自增類型，然后向表中插入兩條數據：
CREATE TABLE `t_test` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`quantity` int(2) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;INSERT INTO `t_test` VALUES ('1', '1');
INSERT INTO `t_test` VALUES ('2', '2');如果有兩個事務更新表中id等于1和2的數據，但更新的順序相反，像下面這樣，就會出現死鎖：
圖片
最后，事務2提示死鎖的錯誤，而事務1則執行成功，當然，在事務的最后需要加上COMMIT語句。查詢表中的數據進行確認，發現id=1的數量更新為了101，而id=2的數量更新成了102。
另外，由于sql執行較快，直接執行上面兩個事務中的sql可能不會產生死鎖的情況，我們可以稍做修改，也就在UPDATE語句后面加上SLEEP函數，SLEEP會讓當前進程暫停執行指定的時間（單位為秒）。分別在兩個事務中執行下面的語句，稍等幾秒鐘，就可以看到出現死鎖：
# 事務1
START TRANSACTION;
UPDATE t_test SET quantity=101 WHERE id = 1;
SELECT SLEEP(10) FROM dual;
UPDATE t_test SET quantity=102 WHERE id = 2;
COMMIT;# 事務2
START TRANSACTION;
UPDATE t_test SET quantity=201 WHERE id = 2;
SELECT SLEEP(10) FROM dual;
UPDATE t_test SET quantity=202 WHERE id = 1;
COMMIT;在MySQL中，死鎖檢測的選項默認是開啟的：innodb_deadlock_detect，如果InnoDB檢測到死鎖，則會把其中一個或者多個事務進行回滾，以這種方式來解決死鎖，InnoDB會嘗試回滾較小的事務。可以通過執行以下命令來查看死鎖的檢測情況：
SHOW ENGINE INNODB STATUS;比如以上兩個事務執行以后，再執行上面的命令，就會看到以下的結果（只摘取死鎖檢測的部分），通過這種方式可以較為清晰的看到死鎖的產生過程：
------------------------
LATEST DETECTED DEADLOCK
------------------------
2023-11-08 15:57:23 0x4df8
*** (1) TRANSACTION:
TRANSACTION 350231, ACTIVE 12 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 1136, 2 row lock(s), undo log entries 1
MySQL thread id 3, OS thread handle 19044, query id 339 localhost ::1 root updating
UPDATE t_test SET quantity=102 WHERE id = 2
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 743 page no 3 n bits 72 index PRIMARY of table `test`.`t_test` trx id 350231 lock_mode X locks rec but not gap waiting
Record lock, heap no 3 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
0: len 4; hex 80000002; asc ;;
1: len 6; hex 000000055818; asc X ;;
2: len 7; hex 2f000001401cb2; asc / @ ;;
3: len 4; hex 800000c9; asc ;;
*** (2) TRANSACTION:
TRANSACTION 350232, ACTIVE 10 sec starting index read, thread declared inside InnoDB 5000
mysql tables in use 1, locked 1
3 lock struct(s), heap size 1136, 2 row lock(s), undo log entries 1
MySQL thread id 5, OS thread handle 19960, query id 340 localhost 127.0.0.1 root updating
UPDATE t_test SET quantity=202 WHERE id = 1
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 743 page no 3 n bits 72 index PRIMARY of table `test`.`t_test` trx id 350232 lock_mode X locks rec but not gap
Record lock, heap no 3 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
0: len 4; hex 80000002; asc ;;
1: len 6; hex 000000055818; asc X ;;
2: len 7; hex 2f000001401cb2; asc / @ ;;
3: len 4; hex 800000c9; asc ;;
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 743 page no 3 n bits 72 index PRIMARY of table `test`.`t_test` trx id 350232 lock_mode X locks rec but not gap waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
0: len 4; hex 80000001; asc ;;
1: len 6; hex 000000055817; asc X ;;
2: len 7; hex 2e0000018d1edf; asc . ;;
3: len 4; hex 80000065; asc e;;
*** WE ROLL BACK TRANSACTION (2)從上面可以看出，MySQL可以檢測到死鎖，并通過回滾事務的方式來打破這種循環等待，但無論如何，在代碼中還是需要盡量減少或者避免死鎖的發生，可以嘗試通過以下方法來達到這樣的目的：
- 讓事務盡可能的小且短；
- 合理設置事務隔離級別；
- 合理設置鎖等待超時時間；
- 確定好事務操作的順序；
- 創建合適的索引，減少加鎖的情況。
以上就是關于MySQL中的死鎖介紹。在實際編碼中，死鎖也是較為常見的一種錯誤，如果對于它不了解，那么碰到這種異常的時候就會顯得手足無措，希望本文有所幫助。
鳴謝：https://dev.mysql.com/doc/refman/5.7/en/
本文轉載自微信公眾號「互聯網全棧架構」，可以通過以下二維碼關注。轉載本文請聯系互聯網全棧架構公眾號。
