mysql死锁检测是自动触发的，innodb在加锁失败时立即检测环形等待并主动回滚牺牲者事务；可通过show engine innodb status或开启innodb_print_all_deadlocks查看详情；预防需统一dml顺序、缩小事务粒度、应用层捕获错误1213重试。
MySQL 死锁检测是自动触发的，不是靠超时
InnoDB 每当检测到两个或多个事务互相等待对方持有的锁（形成环形等待），就会立即启动死锁检测算法，而不是等到 innodb_lock_wait_timeout 超时才处理。这个检测在每次加锁失败、需要等待时都会执行，开销可控但并非零成本。
常见错误现象：Deadlock found when trying to get lock; try restarting transaction 这类报错不是客户端异常，而是 InnoDB 主动选中一个事务作为“牺牲者”并回滚它，让另一个继续执行。
- 死锁检测只在 InnoDB 引擎生效；MyISAM 不支持行锁，自然不涉及死锁
- 检测范围仅限当前实例内，跨 MySQL 实例或跨表锁（如
LOCK TABLES）不会被纳入检测 - 如果事务中混用不同引擎（比如 InnoDB + MyISAM），InnoDB 部分仍参与检测，但 MyISAM 的表级锁会阻塞整个事务，可能掩盖真实死锁路径
如何查看最近一次死锁详情：SHOW ENGINE INNODB STATUS
执行 SHOW ENGINE INNODB STATUSG 后，在输出末尾的 LATEST DETECTED DEADLOCK 区块里能看到完整现场：哪个事务持有什么锁、请求什么锁、事务 ID、SQL 语句、等待链路等。
注意这个信息只保留最后一次死锁记录，且仅对有 PROCESS 权限的用户可见。生产环境建议开启 innodb_print_all_deadlocks = ON，把所有死锁写入错误日志（Error_log），避免错过。
- 日志中出现
*** (1) TRANSACTION:和*** (2) TRANSACTION:表示两个冲突事务 -
WAITING for this LOCK TO BE GRANTED:下面的record locks行告诉你具体卡在哪条记录的哪个索引上 - 若看到
heap no 1，说明是插入意向锁（insert intention lock）冲突，常发生在高并发 INSERT 场景
减少死锁的关键是统一 DML 顺序和缩小事务粒度
死锁无法完全避免，但绝大多数可预防。核心思路是让并发事务以相同顺序访问资源，消除环形等待的可能。
- 按主键或唯一索引值升序更新多行：比如
UPDATE t SET x=1 WHERE id IN (5,2,8)改成WHERE id IN (2,5,8)，确保所有事务都从小到大操作 - 避免在事务中混合执行 select … FOR UPDATE 和普通 UPDATE，尤其不要先查再根据结果更新——容易因查询条件未走索引导致锁住范围过大
- 减少事务中 SQL 数量和执行时间：长事务 = 更长的锁持有时间 = 更高冲突概率；尽量不在事务里调用外部服务或做复杂计算
- 使用
SELECT ... FOR UPDATE NOWAIT或SKIP LOCKED（MySQL 8.0+）主动避开阻塞，而不是被动等待后被卷入死锁
死锁发生后应用层必须重试，不能忽略错误
收到 Deadlock found when trying to get lock 错误时，InnoDB 已经回滚了当前事务的部分或全部语句。此时连接仍处于活跃状态，但事务上下文已丢失——继续执行后续 SQL 会报 ERROR 1305 (42000): SAVEPOINT does not exist 或直接出错。
正确做法是在应用代码中捕获该错误码（MySQL 错误号 1213），显式开启新事务并重试逻辑。注意不是简单重放原 SQL，而是重跑整个业务单元（比如“扣库存 + 写订单”必须一起重试）。
- 重试次数建议控制在 3 次以内，避免雪崩；第 2 次可加入随机退避（如 10–100ms）
- 不要依赖客户端自动重连机制——连接恢复后事务状态已不可控
- 如果重试后持续失败，大概率是设计问题：比如热点行更新（如账户余额）、缺少合适索引导致锁升级为间隙锁等，需回归到 SQL 和索引优化
死锁日志里的锁类型（record lock / gap lock / next-key lock）和索引结构紧密相关，不理解 B+ 树分裂与间隙含义的话，光看死锁信息容易误判根源。