自动检测与回滚#

MySQL自带死锁检测机制（innodb_deadlock_detect），当检测到死锁的时候，数据库会自动回滚其中一个事务，以接触死锁，通常会回滚事务中持有最少资源的那个。

也有锁等待超时的参数（innodb_lock_wait_timeout），当锁等待超过这个时间后，MySQL会自动回滚。

手动kill发生死锁的语句#

可以通过命令，手动快速找出被阻塞的事务以及线程ID，然后手动Kill掉，及时释放资源。

常见降低/排除死锁出现情况的方法#

避免大事务：大事务占据锁耗时长，可以把大事务拆分成多个小事务执行快速释放锁，可以降低死锁产生的概率和冲突
调整申请锁的顺序：在写操作的时候保证能获得足够范围的锁，如修改操作的时候先获取排他锁再获取共享锁，固定顺序访问数据
更改数据隔离级别：可重复读比读已提交多了间隙锁和临键锁，使用读已提交能降低死锁出现的情况。
合理建立索引，减少加锁范围
开启死锁检测，适当调整锁等待超时时间

实际测试#

innodb_print_all_deadlocks：开启死锁打印

1
show VARIABLES like 'innodb_print_all_deadlocks';
2

3
set GLOBAL innodb_print_all_deadlocks = 1;
4

5
flush PRIVILEGES;

1
create table deadlock_test (
2
  id bigint not null,
3
  name varchar(255),
4
  primary key(id)
5
);
6
insert into deadlock_test values(1, 'zhangsan');

1
show engine innodb status;

经典“交叉持锁、互等”死锁：事务 (1) 当前语句是 select * from deadlock_test where id = 1 for update，日志显示它已持有 id=2 的记录锁，正等待获取 id=1 的锁。事务 (2) 当前语句是 select * from deadlock_test where id = 2 for update，日志显示它已持有 id=1 的记录锁，正等待获取 id=2 的锁。二者形成环：T1 持 id=2 等 id=1；T2 持 id=1 等 id=2。锁类型：lock_mode X locks rec but not gap 为记录级行锁（非 GAP 锁），锁定的是主键记录本身。仲裁结果：InnoDB 回滚了事务 (2)（“WE ROLL BACK TRANSACTION (2)”），说明它评估回滚成本更低（未必是开始时间靠后）。

1
------------------------
2
LATEST DETECTED DEADLOCK
3
------------------------
4
2025-09-08 14:25:29 138110019045056
5
*** (1) TRANSACTION:
6
TRANSACTION 48777, ACTIVE 96 sec starting index read
7
mysql tables in use 1, locked 1
8
LOCK WAIT 3 lock struct(s), heap size 1128, 2 row lock(s), undo log entries 1
9
MySQL thread id 638, OS thread handle 138111594002112, query id 479129 10.0.0.8 root statistics
10
select * from deadlock_test where id = 1 for update
11

12
*** (1) HOLDS THE LOCK(S):
13
RECORD LOCKS space id 76 page no 4 n bits 72 index PRIMARY of table `deadlock`.`deadlock_test` trx id 48777 lock_mode X locks rec but not gap
14
Record lock, heap no 3 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
15
 0: len 8; hex 8000000000000002; asc         ;;
16
 1: len 6; hex 00000000be89; asc       ;;
17
 2: len 7; hex 82000001230110; asc     #  ;;
18
 3: len 7; hex 77616e6773616e; asc wangsan;;
19

20

21
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
22
RECORD LOCKS space id 76 page no 4 n bits 72 index PRIMARY of table `deadlock`.`deadlock_test` trx id 48777 lock_mode X locks rec but not gap waiting
23
Record lock, heap no 2 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
24
 0: len 8; hex 8000000000000001; asc         ;;
25
 1: len 6; hex 00000000be80; asc       ;;
26
 2: len 7; hex 01000000be2b14; asc      + ;;
27
 3: len 4; hex 6c697369; asc lisi;;
28

29

30
*** (2) TRANSACTION:
31
TRANSACTION 48768, ACTIVE 149 sec starting index read
32
mysql tables in use 1, locked 1
33
LOCK WAIT 3 lock struct(s), heap size 1128, 2 row lock(s), undo log entries 1
34
MySQL thread id 636, OS thread handle 138111598196416, query id 479151 10.0.0.8 root statistics
35
select * from deadlock_test where id = 2 for update
36

37
*** (2) HOLDS THE LOCK(S):
38
RECORD LOCKS space id 76 page no 4 n bits 72 index PRIMARY of table `deadlock`.`deadlock_test` trx id 48768 lock_mode X locks rec but not gap
39
Record lock, heap no 2 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
40
 0: len 8; hex 8000000000000001; asc         ;;
41
 1: len 6; hex 00000000be80; asc       ;;
42
 2: len 7; hex 01000000be2b14; asc      + ;;
43
 3: len 4; hex 6c697369; asc lisi;;
44

45

46
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
47
RECORD LOCKS space id 76 page no 4 n bits 72 index PRIMARY of table `deadlock`.`deadlock_test` trx id 48768 lock_mode X locks rec but not gap waiting
48
Record lock, heap no 3 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
49
 0: len 8; hex 8000000000000002; asc         ;;
50
 1: len 6; hex 00000000be89; asc       ;;
51
 2: len 7; hex 82000001230110; asc     #  ;;
52
 3: len 7; hex 77616e6773616e; asc wangsan;;
53

54
*** WE ROLL BACK TRANSACTION (2)
55
------------
56
TRANSACTIONS
57
------------
58
Trx id counter 48783
59
Purge done for trx's n:o < 48783 undo n:o < 0 state: running but idle
60
History list length 1
61
LIST OF TRANSACTIONS FOR EACH SESSION:
62
---TRANSACTION 419586600079360, not started
63
0 lock struct(s), heap size 1128, 0 row lock(s)
64
---TRANSACTION 419586600080976, not started
65
0 lock struct(s), heap size 1128, 0 row lock(s)
66
---TRANSACTION 419586600080168, not started
67
0 lock struct(s), heap size 1128, 0 row lock(s)
68
---TRANSACTION 419586600078552, not started
69
0 lock struct(s), heap size 1128, 0 row lock(s)
70
---TRANSACTION 419586600077744, not started
71
0 lock struct(s), heap size 1128, 0 row lock(s)
72
---TRANSACTION 419586600076936, not started
73
0 lock struct(s), heap size 1128, 0 row lock(s)
74
---TRANSACTION 48777, ACTIVE 121 sec
75
5 lock struct(s), heap size 1128, 2 row lock(s), undo log entries 1
76
MySQL thread id 638, OS thread handle 138111594002112, query id 479167 10.0.0.8 root

通过MySQL系统库查询被阻塞的事务以及线程ID，手动kill释放资源

查询锁信息表：

1
-- 8.0 版本以前
2
select * from information_schema.innodb_locks;
3
-- 8.0版本开始
4
select * from performance_schema.data_locks;

关闭死锁检测#

1
SHOW VARIABLES LIKE 'innodb_deadlock_detect';

1
SET GLOBAL innodb_deadlock_detect = 0;

接下来我们再次开两个事务

查询锁等待信息表

1
-- 8.0版本之前
2
select * from information_schema.innodb_lock_waits;
3
-- 8.0版本开始
4
select * from performance_schema.data_lock_waits;

查询innodb事务信息

1
SELECT * from information_schema.INNODB_TRX;

1
-- 列出当前的阻塞者（含可直接 KILL 的进程号）
2
SELECT
3
  b.ENGINE_TRANSACTION_ID   AS blocking_trx_id,
4
  th.PROCESSLIST_ID         AS blocking_pid,
5
  trx.trx_started,
6
  trx.trx_state,
7
  trx.trx_rows_locked,
8
  trx.trx_query
9
FROM performance_schema.data_lock_waits w
10
JOIN performance_schema.data_locks b
11
  ON w.blocking_engine_lock_id = b.engine_lock_id
12
JOIN information_schema.INNODB_TRX trx
13
  ON b.engine_transaction_id = trx.trx_id
14
JOIN performance_schema.threads th
15
  ON b.thread_id = th.thread_id
16
GROUP BY blocking_trx_id, blocking_pid, trx.trx_started, trx.trx_state, trx.trx_rows_locked, trx.trx_query;
17

18
-- 杀掉阻塞会话
19
KILL CONNECTION <blocking_pid>;