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 实时观察锁等待
这两个表能帮你看到当前正在运行的事务及其锁等待关系，适合在问题复现阶段持续监控，但无法回溯已发生的死锁。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
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 语句顺序、索引类型、事务边界，才真正解决问题。
