MySQL死锁的解决办法与长期规避策略

MySQL的死锁是指多个事务相互持有对方所需锁且不释放，导致无限等待的现象。系统内置死锁检测会自动回滚其中一个事务并抛出异常，使另一事务继续执行。要快速应对已发生的死锁并从根源上避免，需掌握以下紧急处理和永久方案。

你现在的核心需求分两步：

1. 紧急处理：已经发生死锁，怎么快速恢复业务？
2. 根治问题：怎么让死锁不再频繁出现？

一、已经产生死锁：3步快速解决

1. 无需手动杀进程！MySQL 会自动处理

MySQL 内置死锁检测（默认开启），一旦检测到死锁：

1. 立即回滚代价最小的那个事务
2. 给应用抛出 Deadlock found when trying to get lock; try restarting transaction 异常
3. 另一个事务会自动继续执行，死锁瞬间解除

结论：已发生的死锁不需要人工干预，MySQL 自己会秒级解决。

2. 查看死锁日志：找到根源（最重要）

死锁已经发生，必须查日志定位原因，执行命令：

-- 查看最近一次死锁的详细信息SHOW ENGINE INNODB STATUS;

在结果中找到 LATEST DETECTED DEADLOCK 段落，里面会告诉你：

1. 哪两个事务死锁了
2. 各自执行的 SQL
3. 各自持有什么锁、等待什么锁
4. 死锁发生的时间

这是解决死锁的唯一依据。

3. 临时应急：卡住的事务不自动解除？

极少数情况（关闭了死锁检测），事务会一直卡住，执行以下命令手动处理：

-- 1. 查看正在运行的事务，找到卡住的 IDSELECT * FROM INFORMATION_SCHEMA.INNODB_TRX;-- 2. 杀掉卡住的事务KILL 事务ID;

二、永久避免死锁：4个核心方案（必做）

死锁无法100%杜绝，但99%的死锁都能通过规范避免。

1. 事务保持短小，不要长事务

1. 死锁概率和事务执行时间成正比
2. 禁止在事务里嵌套：网络请求、文件IO、人工操作、sleep
3. 原则：快进快出，执行完立即提交/回滚

坏例子

BEGIN;UPDATE 表 SET ...;-- 这里调用了外部接口，耗时3秒，锁一直持有，极易死锁COMMIT;

2. 所有表固定访问顺序（最有效）

死锁的本质：访问顺序相反

1. 事务A：先锁订单 → 再锁库存
2. 事务B：先锁库存 → 再锁订单，导致瞬间死锁

解决方案：

所有业务代码，必须按相同顺序操作表/行

例如：统一先操作库存，再操作订单。

3. 给查询条件加索引

无索引会导致行锁升级为表锁，死锁概率暴增。

-- 错误：无索引，会锁全表UPDATE user SET money=100 WHERE name='张三'; -- 正确：name 有索引，只锁单行UPDATE user SET money=100 WHERE name='张三'; 

死锁日志里如果看到 LOCK_MODE: X, REC_NOT_GAP: nil 基本就是无索引导致。

4. 业务代码捕获死锁异常，自动重试

死锁是偶发异常，重试就能成功，这是兜底方案。

Java 示例：

try {    // 执行数据库操作} catch (SQLTransactionRollbackException e) {    if (e.getMessage().contains("Deadlock")) {        // 死锁异常，重试1-2次        retry();    }}

三、快速排查死锁 Checklist

1. 执行 SHOW ENGINE INNODB STATUS; 看死锁详情
2. 检查两个事务是否访问表/行顺序相反
3. 检查更新语句是否没有索引
4. 检查是否有长事务
5. 业务代码是否没有重试机制

总结

死锁发生后MySQL自动回滚一个事务，无需手动干预；通过SHOW ENGINE INNODB STATUS查看原因；根治需固定访问顺序、加索引、短事务与代码重试；业务捕获死锁异常自动重试则可实现用户无感。