死锁不是靠“检测”而是靠“触发后自动发现”
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 语句顺序、索引类型、事务边界，才真正解决问题。
