简介：在数据库高并发场景中，死锁是影响系统稳定性的常见问题之一。本文围绕可重复读隔离级别下的死锁现象展开，结合订单幂等校验的业务案例，系统讲解 Record Lock、Gap Lock、Next-Key Lock 的作用机制以及事务相互等待的形成过程，并给出可落地的避免方案，帮助开发者在设计阶段降低死锁风险。

MySQL 事务死锁的成因分析与避免策略

在数据库开发中，死锁是一个既熟悉又令人头疼的问题。熟悉是因为几乎所有使用关系型数据库的系统都可能遇到它，头疼则在于死锁往往不是由单一因素导致，而是由事务执行顺序、索引设计、隔离级别、SQL 写法等多个维度共同作用产生的。尤其是在高并发业务中，死锁轻则导致个别请求失败，重则引发大量事务回滚，影响系统可用性。

本文将通过一个典型的订单幂等校验场景，深入剖析 MySQL InnoDB 存储引擎在可重复读隔离级别下产生死锁的完整链路，并总结出一套可执行的避免方案。读者在理解锁机制的基础上，能够更从容地应对类似问题。

一、一个真实场景中的死锁现象

假设我们有一个订单表 t_order，其结构如下：

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 上建立了普通索引，也就是非唯一索引。业务上要求订单不能重复，因此在新增订单之前，需要先进行幂等性校验，确认相同订单号的记录是否已经存在。常见做法如下：

-- 事务 A 先查询订单是否已存在
SELECT * FROM t_order WHERE order_no = 1007 FOR UPDATE;
-- 如果不存在，再插入订单
INSERT INTO t_order(order_no, create_date) VALUES (1007, NOW());

这种写法在单事务串行执行的场景下没有问题。但当两个事务同时校验不同的订单号时，就可能出现相互等待的局面。

假设此时表中已有订单号 1001 到 1006 的六条记录。事务 A 要插入订单号 1007，事务 B 要插入订单号 1008。两个事务都先执行 SELECT ... FOR UPDATE 进行查询。由于 order_no 是普通索引，InnoDB 在扫描索引时不仅会锁定命中的记录，还会锁定记录之间的间隙。如果两个事务都未找到目标记录，它们都会对相邻的间隙加 Gap Lock。

接下来，两个事务分别尝试插入自己的订单记录。由于插入操作需要获取插入意向锁，而插入意向锁与对方事务持有的 Gap Lock 不兼容，于是事务 A 等待事务 B 释放间隙锁，事务 B 等待事务 A 释放间隙锁，循环等待形成死锁。

二、死锁的根本原因：锁范围扩大

上述场景中的关键点在于：查询不存在的记录时，普通索引上加的并不是简单的行锁，而是间隙锁。这与 InnoDB 在可重复读隔离级别下解决幻读问题的机制直接相关。

1. 可重复读与幻读

可重复读隔离级别要求一个事务在执行期间，多次读取同一条记录的结果保持一致。然而，仅仅保持已有记录不被修改还不够，因为如果其他事务在两次读取之间插入了新的记录，第二次读取就会多出一些“幻影”数据，这就是幻读。

为了避免幻读，InnoDB 引入了 Next-Key Lock 机制。Next-Key Lock 由两部分组成：

Record Lock：记录锁，锁定索引中的具体记录；
Gap Lock：间隙锁，锁定索引记录之间的空隙，防止其他事务在这些空隙中插入新记录。

当执行 SELECT ... FOR UPDATE 时，InnoDB 会根据查询条件扫描索引，并对扫描到的索引区间加 Next-Key Lock。如果查询条件没有命中任何记录，例如 order_no = 1007 且表中不存在该订单号，InnoDB 仍然会对该订单号可能落入的间隙加 Gap Lock，以确保其他事务无法在这个间隙中插入相同订单号的记录。

2. 为什么两个不同订单号会相互阻塞

在 t_order 表中，假设已有订单号 1001 到 1006。由于 order_no 是普通索引，InnoDB 在扫描 order_no = 1007 时，会从最后一个小于等于 1007 的索引记录开始，向后扫描一定范围。在可重复读隔离级别下，这个过程会对 (1006, +∞) 这个间隙加锁。

同样，事务 B 查询 order_no = 1008 时，也会锁定 (1006, +∞) 这个间隙。这是因为 1007 和 1008 都落在了 1006 之后的最大间隙中。Gap Lock 与 Gap Lock 之间是兼容的，所以两个事务在查询阶段不会阻塞。但当进入插入阶段时，每个事务都要获取插入意向锁，而插入意向锁与已有的 Gap Lock 冲突，于是双方开始互相等待。

3. 死锁的形成条件

这里可以清晰地看到死锁的四个必要条件：

互斥条件：插入意向锁与间隙锁不能同时持有；
持有并等待：事务持有间隙锁，同时等待插入意向锁；
不可剥夺：事务持有的锁只能由自己释放；
循环等待：事务 A 等待事务 B 释放间隙锁，事务 B 等待事务 A 释放间隙锁。

当 InnoDB 的死锁检测机制开启时，系统会主动回滚其中一个事务，从而打破循环等待。但在检测机制关闭或检测延迟的情况下，两个事务会一直处于等待状态，直到锁超时。

三、普通索引为何比主键索引更容易触发间隙锁

值得强调的是，同样的逻辑如果作用在主键索引上，死锁概率会明显降低。原因是主键索引的等值查询可以精确定位到具体记录或具体插入位置，加锁范围更小。而普通索引在等值查询时，如果查询值不存在，InnoDB 仍会从相邻的索引节点出发进行区间锁定，因为非唯一索引无法保证所有值都连续存在。

因此，在普通索引上执行 SELECT ... FOR UPDATE 且查询值不存在时，是一个典型的“锁间隙”场景。这类操作在高并发插入不同键值时，非常容易与插入操作产生冲突。

四、如何避免这类死锁

理解了死锁产生的机制后，避免方案就变得更具针对性。以下是几种经过实践验证的优化思路。

1. 先插入后查询，或者使用唯一索引约束

如果业务允许，优先通过数据库层的唯一索引来保证幂等性，而不是在应用层通过 SELECT ... FOR UPDATE 手工加锁。为 order_no 建立唯一索引后，重复插入会直接返回唯一键冲突，事务无需持有间隙锁，死锁风险大幅降低。

ALTER TABLE t_order ADD UNIQUE KEY uk_order_no(order_no);

应用层只需要捕获唯一键冲突异常即可完成幂等处理。这种方式既简化了业务逻辑，也避免了手工加锁带来的不确定性。

2. 缩小事务范围，减少锁持有时间

事务执行时间越长，锁被持有的时间就越长，与其他事务发生冲突的概率就越高。对于订单场景，可以将查询与插入放在同一个短事务中完成，避免在事务中掺杂远程调用、复杂计算或用户交互等耗时操作。

3. 调整 SQL 写法，避免在普通索引上做不存在的等值查询

如果无法使用唯一索引，可以考虑使用主键进行存在性判断，或者使用 INSERT ... ON DUPLICATE KEY UPDATE 之类的原子操作。此外，对于明确不存在的键值，可以先通过普通查询判断，再执行插入，同时配合业务层分布式锁或队列串行化处理，降低数据库锁竞争。

4. 合理设置死锁检测与锁等待超时

InnoDB 默认开启死锁检测，在死锁发生时能够及时回滚其中一个事务。虽然死锁检测在高并发下有性能开销，但一般情况下建议保持开启。同时可以设置合理的 innodb_lock_wait_timeout，避免未检测到的等待时间过长。

5. 分析死锁日志，持续优化

当死锁发生时，可以通过 SHOW ENGINE INNODB STATUS 查看最近一次死锁的详细信息，包括涉及的事务、持有的锁、等待的锁以及 SQL 语句。定期分析死锁日志，有助于发现系统性的锁竞争模式，从而进行针对性优化。

五、总结

MySQL 中的死锁并不是不可控的“黑盒”问题。它往往源于对锁机制理解不足，以及在高并发场景下使用了不合适的加锁方式。本文通过一个订单幂等校验的案例，展示了普通索引在可重复读隔离级别下的间隙锁行为，以及两个事务如何因插入意向锁与间隙锁冲突而陷入循环等待。

对于开发者而言，最重要的不是死锁发生后如何恢复，而是在设计阶段就识别出潜在的锁竞争点，优先使用数据库自身的唯一性约束与原子操作，减少手工加锁，缩短事务时长，并通过持续监控与日志分析优化系统表现。只有把锁机制理解透彻，才能在复杂并发场景中游刃有余。

MySQL事务死锁的成因分析与避免策略