如何在MySQL中排查Spring声明式事务导致的死锁-mysql教程-PHP中文网

最快查最近死锁用show engine innodb status并定位latest detected deadlock区块，关键看transaction id、holds/waiting for lock及末尾sql；查历史死锁须开启innodb_print_all_deadlocks=1，日志中以** (1) transaction:开头，用grep -a 50 -b 5 "record locks.space id"提取。

如何在mysql中排查spring声明式事务导致的死锁

查 SHOW ENGINE INNODB STATUS 里的 LATEST DETECTED DEADLOCK

死锁发生后，InnoDB 会自动记录最后一次死锁详情，SHOW ENGINE INNODB STATUS 是唯一能立刻拿到完整上下文的命令。重点不是看“谁被回滚”，而是对比两个事务的 query、锁类型（lock_mode X / S）、索引名（index PRIMARY 或 idx_name）和行键值（rec but not gap 或 gap before rec）。

常见误判点：

看到 UPDATE ... WHERE id = ? 就以为是主键锁——如果 id 列没走索引（比如传了字符串或隐式类型转换），实际可能触发全表扫描+间隙锁，扩大死锁面
忽略 *** (1) HOLDS THE LOCK(S) 和 *** (2) WAITING FOR THIS LOCK TO BE GRANTED 的对应关系，导致搞反谁先抢锁、谁后卡住
把 trx_state = 'LOCK WAIT' 当成普通慢查询——它本质是锁冲突，不是 SQL 性能问题

比对事务中 SQL 的执行顺序与索引覆盖情况

Spring 声明式事务本身不决定死锁，但它的方法边界会固化 SQL 执行顺序。比如一个 @Transactional 方法里先后执行：

UPDATE orders SET status='paid' WHERE order_id = 1;
UPDATE inventory SET stock = stock - 1 WHERE product_id = 100;

另一个事务若按相反顺序更新 inventory 再更新 orders，就极易形成循环等待。

排查时必须确认：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

两条 UPDATE 是否都命中了索引？用 EXPLAIN 验证，尤其注意 type 是 const 还是 range 或 ALL
WHERE 条件是否含函数或类型强制转换（如 WHERE product_id = '100'），这会让索引失效，锁范围从单行扩大到间隙
事务内是否有非 DB 操作（如 Feign 调用、文件读写）——它不会出现在死锁日志里，但会拉长持有锁的时间，放大冲突概率

检查 Spring 事务是否真被代理、且 autocommit 已关闭

如果 INNODB_TRX 里压根看不到对应事务，或者 trx_autocommit = 1，说明 Spring 事务根本没生效，所谓“死锁”其实是应用层并发写同一条记录引发的锁等待，和事务机制无关。

典型失效场景：

@Transactional 方法是 private 或 protected —— Spring AOP 无法生成代理，调用走的是原始对象
类内 this.updateOrder() 直接调用另一个 @Transactional 方法——绕过代理，事务切面不触发
方法所在类没被 Spring 管理（缺 @Service），或手动 new XxxService() 实例——容器不介入，更无事务控制
HikariCP 连接池中 connection-test-query 或 validation-timeout 配置不当，导致连接复用时残留旧事务状态

关联 PROCESSLIST 与 jstack 确认线程真实阻塞点

死锁日志只告诉你“哪个 SQL 卡在哪把锁”，但不告诉你“线程为什么卡住”。比如 trx_query 是空、trx_state = 'RUNNING'、trx_started 超 60 秒，大概率是事务方法里调用了外部服务并超时，而数据库连接还握在手里没释放。

此时要同步查：

SELECT ID, USER, HOST, DB, COMMAND, TIME, STATE, INFO FROM information_schema.PROCESSLIST WHERE TIME > 30 AND DB = 'your_db' —— 找出长时间 Sleep 却没断开的连接
用 PROCESSLIST.ID 匹配应用线程 ID，再用 jstack <pid></pid> 查该线程栈，确认它是否卡在 FeignClient、RestTemplate 或 Thread.sleep() 上
若发现大量连接 COMMAND = 'Sleep' 且 TIME 持续增长，基本可判定是 Spring 事务边界外抛异常、未正确回滚，或连接池配置（如 max-lifetime）与 MySQL wait_timeout 不匹配