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 STATUS\G后，在输出末尾的
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+ 树分裂与间隙含义的话，光看死锁信息容易误判根源。
