InnoDB在加锁失败瞬间实时构建等待图检测环，发现即回滚undo日志量最小的事务；检测非定时轮询，而是由锁等待触发，且默认开启innodb_deadlock_detect以保障快速响应与可观测性。
InnoDB 在死锁发生时不是靠定时扫描或被动等待超时，而是在事务加锁失败、进入等待状态的瞬间，实时构建“等待图（wait-for graph）”，检测是否存在循环依赖。一旦发现环（比如事务 A 等待事务 B 持有的锁，而事务 B 又在等待事务 A 持有的锁），立即判定为死锁，并主动回滚其中代价更小的那个事务。
检测是实时触发的，不是轮询
死锁检测不依赖后台线程定期检查，也不按固定间隔运行。它只在以下动作发生时触发：
- 执行
UPDATE、DELETE、SELECT ... FOR UPDATE或INSERT等需要加锁的操作 - 该操作因锁冲突无法立即获得所需锁，转入等待状态
- 此时 InnoDB 立即基于当前所有事务的锁持有与等待关系，生成有向图并判断是否有环
回滚谁？看“undo 日志量”和“修改行数”
InnoDB 不随机选事务回滚，而是估算回滚代价，优先选择以下特征更明显的那个：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 已写入的 undo 日志更少
- 已修改的数据行数更少
- 事务启动时间更晚（非绝对，但常作为辅助参考）
被回滚的事务会收到 ERROR 1213 (40001): Deadlock found when trying to get lock，其持有的所有锁立刻释放，其他等待事务可继续执行。
默认开启且不应关闭
参数 innodb_deadlock_detect 默认为 ON，这是 InnoDB 正常工作的关键机制。若人为关闭：
- 死锁不会被主动发现，只能等
innodb_lock_wait_timeout（默认 50 秒）超时后回滚 - 业务卡顿时间变长，错误日志里显示的是
Lock wait timeout exceeded，而非明确的死锁提示 - 问题更隐蔽，排查难度大幅上升
检测本身开销极小，别为性能关它
现代服务器上，构建和遍历等待图的计算成本几乎可以忽略。关闭检测换来的微弱性能提升，远不如它带来的可观测性和稳定性收益。真正该优化的是事务设计——比如统一访问顺序、避免长事务、确保索引覆盖——而不是削弱检测能力。
