死锁Deadlock是多个事务因循环等待锁资源而永久阻塞的现象。它虽然危险但并不可怕MySQL InnoDB 有自动检测和恢复机制。 死锁是如何产生的死锁的产生必须同时满足四个条件InnoDB 中的死锁通常源于以下两种典型场景不同表相反顺序事务A更新表1再更新表2事务B更新表2再更新表1形成循环等待。相同表不同范围事务A通过范围条件锁定一个间隙事务B锁定另一个间隙随后各自尝试插入对方锁定的间隙导致死锁。注意死锁主要由写操作UPDATE,DELETE,INSERT,SELECT ... FOR UPDATE引起其发生概率不受隔离级别直接影响。 MySQL InnoDB 如何处理死锁MySQL InnoDB 提供了自动处理机制但在极端高并发下也可能需要人工干预。自动检测与回滚默认开启。InnoDB 会构建等待图Wait-for Graph检测到环路后会回滚一个事务“受害者”来打破死锁。通常选择修改行数较少的事务作为回滚对象。兜底超时机制若禁用自动检测或死锁涉及外部锁则依赖innodb_lock_wait_timeout默认50秒。事务等待超时后会自动回滚。深度检测限制当锁等待关系过于复杂如超过200个事务InnoDB 会直接回滚当前事务避免性能崩溃。️ 如何排查死锁死锁排查的核心是获取和分析死锁日志。获取死锁日志查看最近一次死锁执行SHOW ENGINE INNODB STATUS\G在输出中查找LATEST DETECTED DEADLOCK部分。记录所有死锁推荐开启innodb_print_all_deadlocks ON将所有死锁记录到 MySQL 错误日志便于长期追踪。分析死锁日志日志会清晰展示死锁的完整链条。事务信息TRANSACTION块展示了事务ID和状态。持有的锁HOLDS THE LOCK(S)部分显示该事务当前成功获取的锁。等待的锁WAITING FOR THIS LOCK部分显示该事务被阻塞的锁请求。回滚决策日志末尾会标明哪个事务被回滚WE ROLL BACK TRANSACTION。定位根因分析日志中的 SQL 语句和锁资源找出循环等待的路径。通常根因是事务以不一致的顺序访问资源或锁定的范围有重叠。️ 如何预防死锁预防优于处理以下是最佳实践强制统一访问顺序所有事务按相同顺序如主键升序访问表和行。保持事务短小精悍尽快提交减少锁持有时间。使用合适的索引确保WHERE条件能命中索引避免行锁升级为表锁。考虑降低隔离级别若业务允许使用READ COMMITTED级别可减少间隙锁降低死锁概率。使用INSERT ... ON DUPLICATE KEY UPDATE合并先查后改的逻辑减少锁请求次数。 如何从死锁中恢复死锁是并发场景下的常态需要在应用层优雅处理。捕获并重试这是最核心的恢复策略。在代码中捕获死锁异常Deadlock found when trying to get lock; try restarting transaction并进行有限次数的重试通常1-2次即可成功。 总结死锁本质多个事务因循环等待锁而无限阻塞。InnoDB策略默认自动检测并回滚“代价最小”的事务。核心对策统一资源访问顺序缩短事务应用层重试。不要害怕死锁是并发数据库的正常现象设计健壮的重试机制是解决问题的关键。