MySQL 死锁成因深度剖析与规避实践

在订单、支付、库存等高频写入场景中，数据库死锁是开发者经常遇到的棘手问题。它通常不会稳定复现，却会在业务高峰期突然出现，导致事务超时、请求堆积甚至部分业务不可用。本文从一个真实的订单幂等校验案例出发，系统分析 MySQL InnoDB 存储引擎中死锁的产生原因，并给出可落地的规避方案。

一、一个典型的死锁案例

某业务系统需要处理订单的新增、修改与查询。由于订单号不能重复，开发者在新增订单前，会先通过 SELECT ... FOR UPDATE 查询订单是否已存在，只有不存在时才执行插入。这种“先查后插”的幂等校验逻辑，在低并发下运行良好，但当并发量上升后，死锁开始频繁出现。

简化后的表结构如下：

CREATE TABLE `t_order` (
  `id` int NOT NULL AUTO_INCREMENT,
  `order_no` int DEFAULT NULL,
  `create_date` datetime DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `index_order` (`order_no`) USING BTREE
) ENGINE=InnoDB;

其中 id 为主键索引，order_no 为普通非唯一索引。假设表中已有 6 条记录，此时两个事务分别尝试插入订单 1007 和 1008，并且都先执行幂等查询，再执行插入。在可重复读隔离级别下，两个事务会分别对相邻区间加锁，随后在插入时又需要等待对方释放锁，最终形成循环等待，死锁由此产生。

这个案例的关键在于：SELECT ... FOR UPDATE 并不只是“锁一行”，在可重复读隔离级别下，它可能锁住一个范围。

二、为什么会产生死锁？

1. 可重复读与幻读问题

在可重复读隔离级别下，普通 SELECT 通过 MVCC 保证同一事务多次读取结果一致，但无法阻止其他事务插入新记录，因此可能出现幻读。为了在锁定读场景下避免幻读，InnoDB 引入了临键锁（Next-Key Lock）。

临键锁由两部分组成：

• 记录锁（Record Lock）：锁定索引记录本身。
• 间隙锁（Gap Lock）：锁定两个索引值之间的空隙，阻止其他事务在间隙中插入新记录。

当执行 SELECT ... FOR UPDATE 且查询条件命中普通索引时，InnoDB 往往会对命中记录及其相邻间隙加临键锁。如果查询条件对应的记录不存在，则可能退化为间隙锁，锁住一个区间。

2. 加锁顺序不一致导致循环等待

死锁的根本原因是多个事务以不同顺序持有并等待锁资源。在上述案例中：

• 事务 A 查询订单 1007，对某个间隙加锁；
• 事务 B 查询订单 1008，对相邻间隙加锁；
• 事务 A 执行插入，需要等待事务 B 释放间隙锁；
• 事务 B 执行插入，需要等待事务 A 释放间隙锁。

双方各自持有对方需要的锁，形成循环等待，InnoDB 死锁检测机制一旦发现环路，就会回滚其中一个事务。

3. 唯一索引与普通索引的差异

如果 order_no 是唯一索引，情况会有所不同。唯一索引等值查询且记录存在时，通常只需加记录锁；记录不存在时，可能加间隙锁。若插入时发生唯一键冲突，还会涉及共享锁与排他锁的转换，同样可能引发死锁。因此，索引类型会直接影响加锁范围与死锁概率。

4. 锁范围扩大与长事务

以下行为会显著放大死锁风险：

• 查询条件未命中索引或索引选择性差，导致扫描大量记录并加锁；
• 事务中包含远程调用、文件操作等耗时逻辑，拉长持锁时间；
• 批量操作未控制顺序，多个事务交叉加锁；
• 并发量突增，锁等待链变长。

三、如何避免死锁？

1. 固定数据访问顺序

让所有事务按相同顺序访问相同资源，是预防死锁最有效的手段之一。例如按订单号排序后再批量处理，避免交叉加锁。

2. 缩小事务粒度与持锁时间

将查询、校验、插入拆分为更短的事务，避免在事务中执行网络请求或复杂计算。能不用 SELECT ... FOR UPDATE 的场景，尽量用唯一索引约束配合 INSERT ... ON DUPLICATE KEY UPDATE 或先插入后捕获唯一键冲突来实现幂等。

3. 优化索引与查询条件

确保查询走索引，减少扫描行数与加锁范围。对于幂等校验，优先使用唯一索引，让数据库约束来保证唯一性，而不是依赖范围锁定读。

4. 降低隔离级别或调整加锁策略

在业务允许的前提下，可评估使用读已提交隔离级别，减少间隙锁带来的冲突。但需注意，这会影响幻读语义，必须结合业务一致性要求谨慎选择。

5. 控制并发与增加重试机制

对同一类资源的并发操作进行限流或串行化处理。同时，应用层应捕获死锁异常并执行有限次重试，避免直接失败影响用户体验。

6. 监控与诊断

开启死锁检测后，可通过 SHOW ENGINE INNODB STATUS 查看最近一次死锁信息，结合慢查询日志与锁等待监控，定位高频冲突点并持续优化。

四、总结

MySQL 死锁并非不可战胜，它本质上是并发事务对锁资源竞争的结果。理解临键锁、间隙锁与记录锁的作用机制，识别加锁顺序不一致、锁范围扩大、长事务等诱因，再通过固定访问顺序、优化索引、缩小事务、合理重试等手段，可以显著降低死锁发生概率。在百度智能云等云数据库环境中，还可结合监控告警与性能分析工具，持续观测锁等待与死锁指标，让数据库在高并发下保持稳定运行。