前言：

在 MySQL 運維過程中，鎖等待和死鎖問題是令各位 DBA 及開發同學非常頭痛的事。出現此類問題會造成業務回滾、卡頓等故障，特別是業務繁忙的系統，出現死鎖問題後影響會更嚴重。本篇文章我們一起來學習下什麼是鎖等待及死鎖，出現此類問題又應該如何分析處理呢？

1.瞭解鎖等待與死鎖

出現鎖等待或死鎖的原因是訪問資料庫需要加鎖，那你可能要問了，為啥要加鎖呢？原因是為了確保併發更新場景下的資料正確性，保證資料庫事務的隔離性。

試想一個場景，如果你要去圖書館借一本《高效能MySQL》，為了防止有人提前把這本書借走，你可以提前進行預約（加鎖），這把鎖可以怎麼加？

• 封鎖圖書館（資料庫級別的鎖）
• 把資料庫相關的書都鎖住（表級別的鎖）
• 只鎖 MySQL 相關的書（頁級別的鎖）
• 只鎖《高效能MySQL》這本書（行級別的鎖）

鎖的粒度越細，併發級別越高，實現也更復雜。

鎖等待也可稱為事務等待，後執行的事務等待前面處理的事務釋放鎖，但是等待時間超過了 MySQL 的鎖等待時間，就會引發這個異常。等待超時後的報錯為“Lock wait timeout exceeded…”。

死鎖發生的原因是兩個事務互相等待對方釋放相同資源的鎖，從而造成的死迴圈。產生死鎖後會立即報錯“Deadlock found when trying to get lock…”。

2.現象復現及處理

下面我們以 MySQL 5.7.23 版本為例（隔離級別是 RR ），來複現下上述兩種異常現象。

1. mysql> show create table test_tb\G
2. *************************** 1. row ***************************
3. Table: test_tb
4. Create Table: CREATE TABLE `test_tb` (
5. `id` int(11) NOT NULL AUTO_INCREMENT,
6. `col1` varchar(50) NOT NULL DEFAULT '',
7. `col2` int(11) NOT NULL DEFAULT '1',
8. `col3` varchar(20) NOT NULL DEFAULT '',
9. PRIMARY KEY (`id`),
10. KEY `idx_col1` (`col1`)
11. ) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8
12. 1 row in set (0.00 sec)
14. mysql> select * from test_tb;
15. +----+------+------+------+
16. | id | col1 | col2 | col3 |
17. +----+------+------+------+
18. | 1 | fdg | 1 | abc |
19. | 2 | a | 2 | fg |
20. | 3 | ghrv | 2 | rhdv |
21. +----+------+------+------+
22. 3 rows in set (0.00 sec)
24. # 事務一首先執行
25. mysql> begin;
26. Query OK, 0 rows affected (0.00 sec)
28. mysql> select * from test_tb where col1 = 'a' for update;
29. +----+------+------+------+
30. | id | col1 | col2 | col3 |
31. +----+------+------+------+
32. | 2 | a | 2 | fg |
33. +----+------+------+------+
34. 1 row in set (0.00 sec)
36. # 事務二然後執行
37. mysql> begin;
38. Query OK, 0 rows affected (0.01 sec)
40. mysql> update test_tb set col2 = 1 where col1 = 'a';
41. ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

出現上種異常的原因是事務二在等待事務一的行鎖，但事務一一直沒提交，等待超時而報錯。InnoDB 行鎖等待超時時間由 innodb_lock_wait_timeout 引數控制，此引數預設值為 50 ，單位為秒，即預設情況下，事務二會等待 50s ，若仍拿不到行鎖則會報等待超時異常並回滾此條語句。

對於 5.7 版本，出現鎖等待時，我們可以檢視 information_schema 中的幾張系統表來查詢事務狀態。

• innodb_trx 當前執行的所有事務。
• innodb_locks 當前出現的鎖。
• innodb_lock_waits 鎖等待的對應關係

1. # 鎖等待發生時 檢視innodb_trx表可以看到所有事務
2. # trx_state值為LOCK WAIT 則代表該事務處於等待狀態
4. mysql> select * from information_schema.innodb_trx\G
5. *************************** 1. row ***************************
6. trx_id: 38511
7. trx_state: LOCK WAIT
8. trx_started: 2021-03-24 17:20:43
9. trx_requested_lock_id: 38511:156:4:2
10. trx_wait_started: 2021-03-24 17:20:43
11. trx_weight: 2
12. trx_mysql_thread_id: 1668447
13. trx_query: update test_tb set col2 = 1 where col1 = 'a'
14. trx_operation_state: starting index read
15. trx_tables_in_use: 1
16. trx_tables_locked: 1
17. trx_lock_structs: 2
18. trx_lock_memory_bytes: 1136
19. trx_rows_locked: 1
20. trx_rows_modified: 0
21. trx_concurrency_tickets: 0
22. trx_isolation_level: REPEATABLE READ
23. trx_unique_checks: 1
24. trx_foreign_key_checks: 1
25. trx_last_foreign_key_error: NULL
26. trx_adaptive_hash_latched: 0
27. trx_adaptive_hash_timeout: 0
28. trx_is_read_only: 0
29. trx_autocommit_non_locking: 0
30. *************************** 2. row ***************************
31. trx_id: 38510
32. trx_state: RUNNING
33. trx_started: 2021-03-24 17:18:54
34. trx_requested_lock_id: NULL
35. trx_wait_started: NULL
36. trx_weight: 4
37. trx_mysql_thread_id: 1667530
38. trx_query: NULL
39. trx_operation_state: NULL
40. trx_tables_in_use: 0
41. trx_tables_locked: 1
42. trx_lock_structs: 4
43. trx_lock_memory_bytes: 1136
44. trx_rows_locked: 3
45. trx_rows_modified: 0
46. trx_concurrency_tickets: 0
47. trx_isolation_level: REPEATABLE READ
48. trx_unique_checks: 1
49. trx_foreign_key_checks: 1
50. trx_last_foreign_key_error: NULL
51. trx_adaptive_hash_latched: 0
52. trx_adaptive_hash_timeout: 0
53. trx_is_read_only: 0
54. trx_autocommit_non_locking: 0
55. 2 rows in set (0.00 sec)
57. # innodb_trx 欄位值含義
58. trx_id：事務ID。
59. trx_state：事務狀態，有以下幾種狀態：RUNNING、LOCK WAIT、ROLLING BACK 和 COMMITTING。
60. trx_started：事務開始時間。
61. trx_requested_lock_id：事務當前正在等待鎖的標識，可以和 INNODB_LOCKS 表 JOIN 以得到更多詳細資訊。
62. trx_wait_started：事務開始等待的時間。
63. trx_weight：事務的權重。
64. trx_mysql_thread_id：事務執行緒 ID，可以和 PROCESSLIST 表 JOIN。
65. trx_query：事務正在執行的 SQL 語句。
66. trx_operation_state：事務當前操作狀態。
67. trx_tables_in_use：當前事務執行的 SQL 中使用的表的個數。
68. trx_tables_locked：當前執行 SQL 的行鎖數量。
69. trx_lock_structs：事務保留的鎖數量。
70. trx_isolation_level：當前事務的隔離級別。
72. # sys.innodb_lock_waits 檢視也可看到事務等待狀況，且給出了殺連結的SQL
73. mysql> select * from sys.innodb_lock_waits\G
74. *************************** 1. row ***************************
75. wait_started: 2021-03-24 17:20:43
76. wait_age: 00:00:22
77. wait_age_secs: 22
78. locked_table: `testdb`.`test_tb`
79. locked_index: idx_col1
80. locked_type: RECORD
81. waiting_trx_id: 38511
82. waiting_trx_started: 2021-03-24 17:20:43
83. waiting_trx_age: 00:00:22
84. waiting_trx_rows_locked: 1
85. waiting_trx_rows_modified: 0
86. waiting_pid: 1668447
87. waiting_query: update test_tb set col2 = 1 where col1 = 'a'
88. waiting_lock_id: 38511:156:4:2
89. waiting_lock_mode: X
90. blocking_trx_id: 38510
91. blocking_pid: 1667530
92. blocking_query: NULL
93. blocking_lock_id: 38510:156:4:2
94. blocking_lock_mode: X
95. blocking_trx_started: 2021-03-24 17:18:54
96. blocking_trx_age: 00:02:11
97. blocking_trx_rows_locked: 3
98. blocking_trx_rows_modified: 0
99. sql_kill_blocking_query: KILL QUERY 1667530
100. sql_kill_blocking_connection: KILL 1667530

sys.innodb_lock_waits 檢視整合了事務等待狀況，同時給出殺掉堵塞源端的 kill 語句。不過是否要殺掉連結還是需要綜合考慮的。

死鎖與鎖等待稍有不同，我們同樣也來簡單復現下死鎖現象。

1. # 開啟兩個事務
2. # 事務一執行
3. mysql> update test_tb set col2 = 1 where col1 = 'a';
4. Query OK, 1 row affected (0.00 sec)
5. Rows matched: 1 Changed: 1 Warnings: 0
7. # 事務二執行
8. mysql> update test_tb set col2 = 1 where id = 3;
9. Query OK, 1 row affected (0.00 sec)
10. Rows matched: 1 Changed: 1 Warnings: 0
12. # 回到事務一執行 回車後 此條語句處於鎖等待狀態
13. mysql> update test_tb set col1 = 'abcd' where id = 3;
14. Query OK, 1 row affected (5.71 sec)
15. Rows matched: 1 Changed: 1 Warnings: 0
16. # 回到事務二再執行 此時二者相互等待發生死鎖
17. mysql> update test_tb set col3 = 'gddx' where col1 = 'a';
18. ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction

發生死鎖後會選擇一個事務進行回滾，想查明死鎖原因，可以執行 show engine innodb status 來檢視死鎖日誌，根據死鎖日誌，結合業務邏輯來進一步定位死鎖原因。

在實際應用中，我們要儘量避免死鎖現象的發生，可以從以下幾個方面入手：

• 事務儘可能小，不要將複雜邏輯放進一個事務裡。
• 涉及多行記錄時，約定不同事務以相同順序訪問。
• 業務中要及時提交或者回滾事務，可減少死鎖產生的概率。
• 表要有合適的索引。
• 可嘗試將隔離級別改為 RC 。

總結：

本篇文章簡單介紹了鎖等待及死鎖發生的原因，其實真實業務中發生死鎖還是很難分析的，需要一定的經驗積累。本篇文章只是面向初學者，希望各位對死鎖能夠有個簡單的印象。