1.6 死锁排查全攻略：如何快速定位并解决MySQL死锁问题
📚 学习目标
通过本节学习，你将掌握：
- ✅ 死锁的成因分析和典型场景识别
- ✅ 死锁日志的解读和分析方法
- ✅ 快速定位死锁问题的工具和技巧
- ✅ 死锁预防策略和最佳实践
- ✅ 应用层死锁处理机制（重试、乐观锁等）
🎯 学习收获
学完本节后，你将能够：
- 快速定位：5分钟内定位死锁的根本原因
- 问题解决：设计有效的死锁预防和解决方案
- 系统优化：通过架构设计避免死锁发生
- 应急处理：建立完善的死锁监控和告警体系
💡 实际场景引入
场景一：促销活动引发的死锁风暴
问题描述：某电商平台在双11促销期间，大量用户同时抢购热门商品。系统频繁出现死锁错误，导致部分订单处理失败。通过监控发现，死锁主要发生在库存扣减操作中。
你的任务：如何快速定位死锁原因，并设计解决方案避免死锁？
场景二：转账业务中的死锁问题
问题描述：某金融系统的转账功能，当多个用户同时进行转账操作时，偶尔会出现死锁。虽然MySQL会自动回滚其中一个事务，但用户体验受到影响。
你的任务：如何分析死锁日志，并优化业务逻辑避免死锁？
死锁是数据库系统中最棘手的问题之一，特别是在高并发的业务场景中。当多个事务相互等待对方持有的资源锁时，就会形成死锁，导致事务无法继续执行。深入理解死锁的成因、排查方法和预防策略，对保障数据库稳定运行至关重要。本节将为你提供一套完整的死锁排查和解决方案。
什么是死锁？
死锁是指两个或多个事务在执行过程中，因争夺资源而造成的一种互相等待的现象，若无外力作用，它们都将无法推进下去。
死锁的四个必要条件
- 互斥条件：一个资源每次只能被一个事务使用
- 请求和保持条件：事务已经保持了至少一个资源，同时又在请求其他被别的事务占有的资源
- 不可剥夺条件：事务已获得的资源在未使用完之前不能强行剥夺
- 环路等待条件：存在一种事务资源的循环等待链
死锁示意图
死锁产生的典型场景
场景一：交叉更新
这是最常见的死锁场景：
-- 会话1执行BEGIN;UPDATEemployeesSETsalary=55000WHEREemp_no=10001;-- 等待一会再执行下一步-- 会话2执行BEGIN;UPDATEemployeesSETsalary=60000WHEREemp_no=10002;UPDATEemployeesSETsalary=56000WHEREemp_no=10001;-- 此时会阻塞-- 回到会话1执行UPDATEemployeesSETsalary=61000WHEREemp_no=10002;-- 死锁发生！场景二：不同顺序的索引更新
-- 假设表有两个索引：PRIMARY(emp_no) 和 idx_dept_no(dept_no)-- 会话1BEGIN;UPDATEemployeesSETdept_no='d002'WHEREemp_no=10001;-- 等待一会再执行下一步-- 会话2BEGIN;UPDATEemployeesSETdept_no='d001'WHEREemp_no=10002;UPDATEemployeesSETdept_no='d002'WHEREemp_no=10003;-- 可能阻塞-- 回到会话1UPDATEemployeesSETdept_no='d001'WHEREemp_no=10002;-- 死锁可能发生场景三：间隙锁冲突
在可重复读隔离级别下，范围查询会产生间隙锁：
-- 表中emp_no数据: 10001, 10002, 10005, 10008-- 会话1BEGIN;SELECT*FROMemployeesWHEREemp_noBETWEEN10003AND10006FORUPDATE;-- 锁住了(10002, 10005]区间-- 会话2BEGIN;SELECT*FROMemployeesWHEREemp_noBETWEEN10004AND10007FORUPDATE;-- 锁住了(10002, 10005]和(10005, 10008]区间-- 会话1INSERTINTOemployeesVALUES(10007,'1990-01-01','John','Doe','M','2020-01-01');-- 可能发生死锁死锁检测机制
MySQL的InnoDB存储引擎内置了死锁检测机制。
死锁检测原理
InnoDB使用等待图（waits-for graph）来检测死锁：
