mysql并发事务中如何检测死锁_mysql异常排查方法

mysql死锁由InnoDB自动检测并回滚代价最小事务，排查应聚焦错误日志与SHOW ENGINE INNODB STATUS中的LATEST DETECTED DEADLOCK，结合INNODB_TRX和INNODB_LOCK_WaiTS实时监控，根本解决需统一SQL执行顺序、优化索引、缩短事务及指数退避重试。

死锁不是靠“检测”而是靠“触发后自动发现”

MySQL 的 InnoDB 存储引擎本身不提供主动轮询或预判死锁的机制。它只在事务尝试获取锁失败、且等待链构成环时，由 deadlock detector 在几毫秒内识别并强制回滚其中**代价最小的事务**（通常看 undo log 大小和事务执行时间）。你看到的 Deadlock found when trying to get lock 错误，就是这个机制生效后的结果，不是你手动检测出来的。

所以排查重点不是“怎么提前发现死锁”，而是“为什么每次都在这里报错”——得从错误日志入手还原现场。

从 SHOW ENGINE INNODB STATUS 拿到死锁详情

这是最直接、最常用的方法。执行后输出里最关键的段落是 LATEST DETECTED DEADLOCK，里面包含两个（或多个）事务各自的 SQL、持有的锁、等待的锁、以及 InnoDB 选择回滚哪个事务的理由。

• 必须在死锁发生后**尽快执行**，该信息是覆盖式刷新的，下次死锁会覆盖上一次内容
• 注意看 *** (1) TRANSACTION 和 *** (2) TRANSACTION 两段，分别对应两个冲突事务
• 重点关注每段末尾的 mysql tables in use、locked tables、LOCK WAIT 行，能看出锁类型（RECORD LOCKS 还是 GEN_CLUST_INDEX）、锁住的索引记录（如 space id 123 page no 456 n bits 72）
• 如果事务正在执行的是 UPDATE 或 delete，检查 WHERE 条件是否命中了**非唯一索引**或**没走索引**——这极易导致锁范围扩大，诱发死锁

用 information_schema.INNODB_TRX 和 INNODB_LOCK_WAITS 实时观察锁等待

这两个表能帮你看到当前正在运行的事务及其锁等待关系，适合在问题复现阶段持续监控，但无法回溯已发生的死锁。

SELECT    trx_id, trx_state, trx_started, trx_wait_started,   trx_mysql_thread_id, trx_query FROM information_schema.INNODB_TRX  WHERE trx_state = 'LOCK WAIT';

再关联 INNODB_LOCK_WAITS 可查出谁在等谁：

SELECT    r.trx_id waiting_trx_id,   r.trx_mysql_thread_id waiting_thread,   r.trx_query waiting_query,   b.trx_id blocking_trx_id,   b.trx_mysql_thread_id blocking_thread,   b.trx_query blocking_query FROM information_schema.INNODB_LOCK_WAITS w JOIN information_schema.INNODB_TRX b ON b.trx_id = w.blocking_trx_id JOIN information_schema.INNODB_TRX r ON r.trx_id = w.requesting_trx_id;

注意：INNODB_LOCK_WAITS 只有在存在锁等待时才有数据；且这些表查询本身有一定开销，不要高频轮询生产库。

避免死锁比排查更有效：关键设计原则

多数死锁源于事务内 SQL 执行顺序不一致或锁粒度失控。真正要改的不是排查手段，而是代码逻辑和索引设计。

• 所有涉及多行更新的事务，**固定操作顺序**：比如按 user_id 升序更新订单，就始终先 ORDER BY user_id ASC 再遍历处理
• 确保 UPDATE/DELETE 的 WHERE 条件能命中**唯一索引或主键**，避免全表扫描或间隙锁扩散
• 减少事务长度：把非数据库操作（如 http 调用、文件写入）移出事务块；批量更新拆成小批次（如每次 100 行），降低单次锁持有时间
• 应用层捕获 Deadlock found when trying to get lock 异常，并做**指数退避重试**（最多 2–3 次），而不是直接报错给用户

死锁日志里的锁地址（如 space id 123 page no 456）对开发几乎无意义，别花时间解码它。盯住 SQL 语句顺序、索引类型、事务边界，才真正解决问题。