MySQL 中如果发生死锁应该如何解决？

MySQL 中如果发生死锁应该如何解决

死锁：两个或多个事务，互相持有对方需要的锁，双方都在等待对方释放锁，互相僵持，谁都无法继续执行。InnoDB会自动检测死锁，主动回滚代价更小的那个事务，另一个事务继续执行。

一、怎么发现死锁

1. 程序抛出异常：Deadlock found when trying to get lock; try restarting transaction
2. MySQL查看死锁日志

show engine innodb status;

输出结果里 LATEST DETECTED DEADLOCK 就是最近一次死锁记录，可以看到哪两条SQL、锁、事务造成死锁。

二、死锁产生的4个必要条件

1. 互斥：锁是排他的
2. 持有并等待：事务拿到部分锁，等待其他锁
3. 不可剥夺：锁不能被强制抢走，只能自己释放
4. 循环等待：形成环路等待（A等B、B等A）

破坏任意一个条件就可以消除死锁。

三、线上解决、优化方案（面试重点）

1. 业务捕获异常，重试

InnoDB回滚其中一个事务，应用捕获死锁异常，做有限次数重试，不要无限重试。

这是兜底方案，不能只靠重试，要从根源避免。

2. 统一更新资源顺序（最有效）

死锁大多来自更新顺序不一致。

• 事务A：更新id=1，再更新id=2
• 事务B：更新id=2，再更新id=1
  会形成循环等待产生死锁。

✅优化：所有业务，永远按主键id从小到大顺序更新记录，破坏循环等待条件。

3. 尽量缩小事务粒度

事务不要写太大，事务内部不要做耗时操作（网络调用、sleep）。

事务越快执行完成，锁持有时间越短，发生锁竞争、死锁概率大幅降低。

不要把查询、外部接口调用放到事务里面。

4. 减少范围操作，避免间隙锁冲突（RR隔离级别）

RR隔离级别临键锁/间隙锁很容易诱发死锁。

• 尽量走索引，避免全表扫描，防止锁范围扩大；
• 互联网很多业务改成RC隔离级别，RC没有间隙锁，死锁概率显著下降；

修改RC前提：binlog格式设置为ROW。

5. 避免一次性操作过多行

大批量update/delete，拆成分批小SQL，减少持有大量行锁。

6. 谨慎使用 select ... for update

尽量精准查询，命中唯一索引，锁住少量行；不要范围查询for update，锁范围会很大。

四、紧急处理：已经发生死锁，怎么应急

1. 通过 show engine innodb status 拿到死锁日志，定位业务SQL；
2. show processlist 找到长时间阻塞事务，可以kill掉阻塞会话；
3. 优化SQL、调整业务更新顺序。

补充：死锁 vs 锁等待超时

• 死锁：互相等，InnoDB自动检测，回滚一个事务，报错死锁。
• 锁等待超时 ：一个事务单纯等锁，对方不释放，超过innodb_lock_wait_timeout时间直接报错，不会自动回滚对方事务。

总结：

发生死锁InnoDB会自动回滚代价小的事务；应用层捕获异常有限重试；根治手段：统一更新记录顺序、缩小事务、避免长事务；RR隔离级别间隙锁容易诱发死锁，可评估业务是否切换RC；通过show engine innodb status分析死锁日志定位问题SQL。