从一次订单死锁故障，聊聊 MySQL 锁机制与排查实践

各位后端的老铁，我是老王。

当年做电商订单中心和支付网关的时候，我最怕半夜两点手机响。只要报警短信里带「Deadlock found when trying to get lock」，基本意味着有大促漏斗或者并发量冲上来了，接着就是一连串因事务挂起导致的数据库连接池被打满。

今天老王不背书，结合我之前踩过的几个大坑，从底层逻辑、真实案例因果链和排查套路三个维度，把 MySQL (InnoDB) 的锁机制和死锁彻底拆解一遍。

一、 先看清对手：InnoDB 锁机制的因果链

很多刚从 Java 或 Golang 转入高并发业务开发的同学，往往以为「我改这一行，就只锁这一行」。在 InnoDB 里，这个直觉是完全错的。

InnoDB 的锁机制有一条铁律：锁是加在索引上的，而不是加在记录上的。如果查询没有走索引，它就会退化为全表扫描并锁住整张表。

在默认的 Repeatable Read (RR) 隔离级别下，为了解决幻读，InnoDB 引入了间隙锁。因果链条是这样的：

• 记录锁 (Record Lock)：命中精准索引且记录存在，锁住单行。
• 间隙锁 (Gap Lock)：锁定一个开区间，阻止其他事务向这个区间插入新数据。注意：间隙锁与间隙锁之间并不互斥，它们存在的唯一目的就是阻止别人 INSERT。
• 临键锁 (Next-Key Lock)：Record Lock + Gap Lock 的组合，锁定左开右闭区间（比如 (10, 20]）。InnoDB 默认使用 Next-Key Lock，只有在特定条件下（如唯一索引等值查询命中）才会降级为 Record Lock。
• 插入意向锁 (Insert Intention Lock)：一种特殊的间隙锁。在插入之前，如果目标间隙被加了 Gap Lock，INSERT 操作就会挂起，申请插入意向锁等待。

死锁的本质，就是两个或两个以上的事务，持有了对方下一步需要的锁资源，同时还在等待对方释放锁，形成了闭环。

二、 真实翻车案例：支付流水的「幽灵死锁」

1. 业务背景

那是在做第三方支付回调处理时，本地有一张支付流水表 pay_flow，结构简化如下：

CREATE TABLE `pay_flow` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `order_no` varchar(64) NOT NULL,
  `status` tinyint(4) NOT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_order_no` (`order_no`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

业务逻辑很简单：第三方支付异步通知回调，为了防止重复处理，先 SELECT ... FOR UPDATE 查一下，如果不存在就写入，存在就更新。代码用 Go 写的，开了一个事务：

tx := db.Begin()
// 1. 查询订单是否存在
var flow PayFlow
err := tx.Raw("SELECT id, order_no, status FROM pay_flow WHERE order_no = ? FOR UPDATE", orderNo).Scan(&flow).Error

// 2. 如果不存在则插入
if errors.Is(err, gorm.ErrRecordNotFound) {
    tx.Exec("INSERT INTO pay_flow(order_no, status) VALUES (?, ?)", orderNo, 1)
}
tx.Commit()

2. 死锁复现与因果链

压测时，当两个不同的线程几乎同时处理两个系统中不存在的订单（比如 order_no = 'A100' 和 order_no = 'B200'）时，DB 瞬时抛出死锁异常。

让我们来看看这背后的因果死环：

[事务 1 (A100)]                         [事务 2 (B200)]
      |                                       |
1. SELECT FOR UPDATE (A100 不存在)            |
   -> 获得 idx_order_no 上的 Gap 锁           |
      |                                 2. SELECT FOR UPDATE (B200 不存在)
      |                                    -> 也获得了同一区间的 Gap 锁
      |                                       (间隙锁互不排斥，两者和平共处)
      |                                       |
3. INSERT INTO (A100)                         |
   -> 需要在间隙中插入数据                     |
   -> 被事务 2 的 Gap 锁阻塞                  |
   -> 进入等待 (等待事务 2 提交)              |
      |                                 4. INSERT INTO (B200)
      |                                    -> 也需要在该间隙插入数据
      |                                    -> 被事务 1 的 Gap 锁阻塞
      |                                    -> 形成闭环！
      |                                       |
   [ MySQL 检测到死锁，根据成本回滚了其中一个事务 ]

看到了吗？正是因为两个事务都拿到了兼容的 Gap Lock，随后又同时想要往对方锁定的间隙里插入数据（申请插入意向锁），直接打成死结。

三、 老王的死锁排查四步法

出了死锁别慌，按老王的套路走，十五分钟内定位根因：

第一步：抓现场 —— 调取死锁日志

在 MySQL 终端中直接执行：

SHOW ENGINE INNODB STATUS\G

找到 ------------------------ LATEST DETECTED DEADLOCK ------------------------ 这一段。

第二步：看日志，提炼关键要素

日志里重点关注两块：(1) TRANSACTION 和 (2) TRANSACTION。

1. 持有锁情况：看 HOLDS THE LOCK(S)，找清楚事务持有的是什么锁（lock_mode X 是排他锁，locks gap before rec 说明带间隙）。
2. 等待锁情况：看 WAITING FOR THIS LOCK TO BE GRANTED，重点看 insert_intention、lock_mode X waiting。
3. 执行的 SQL：找到诱发死锁的最终那句 SQL（注意：日志只显示死锁时最后执行的一条 SQL，前面持锁的 SQL 往往需要去应用层查调用链路）。

第三步：代码还原因果链

拿死锁日志里的 SQL，去 Java/Go 代码里找对应的方法。看这个方法所在的本地事务里，从事务开始到死锁发生，中间到底依次执行了哪些操作。

第四步：在测试环境 EXPLAIN 锁范围

很多人看 SQL 以为走的是主键，其实由于隐式转换或者优化器抽风走了全表扫描。 用 EXPLAIN 查看执行计划，重点关注 type、key 和 rows。

四、 架构与研发避坑指南

结合做订单和分布式系统的经验，老王总结了几条治理死锁的「硬规则」：

1. 降低隔离级别：RC 替代 RR

这是很多大厂互联网业务的标配方案。 把隔离级别改为 Read Committed (RC)，同时配合 binlog_format = ROW。在 RC 级别下，除了外键约束和重复键检查，InnoDB 默认不开启 Gap Lock，能直接灭掉 70% 以上莫名其妙的间隙死锁。

2. 将「SELECT FOR UPDATE + INSERT」改为唯一索引冲突捕获

上面的支付流水案例，改写思路很直接： 别查了，利用数据库的唯一索引（UNIQUE KEY idx_order_no）。直接 INSERT，通过捕获数据库的 DuplicateKey 异常（Java 中是 DuplicateKeyException，Go 里判断特定驱动错误码），捕获到就走 UPDATE 逻辑；或者直接用 INSERT INTO ... ON DUPLICATE KEY UPDATE（但注意该语句在某些场景下也有锁升级陷阱，需控制并发路径）。

3. 严格规范事务内的加锁顺序

如果你的事务需要批量更新多条记录，比如扣减库存：

• 错误写法：入参传什么顺序，就按什么顺序 UPDATE ... WHERE id = ?。
  • 事务 A 先锁 1 再锁 2；事务 B 先锁 2 再锁 1，极高概率死锁。
• 正确写法：在内存中对主键或者唯一键先做严格排序（从小到大），然后按顺序执行 SQL。大家都按同一个顺序拿锁，只会出现等待，绝不会死锁。

// Java 示例：批量操作必须先排好序再进 DB
List<Long> sortedIds = goodsList.stream()
                                .map(Goods::getId)
                                .sorted()
                                .collect(Collectors.toList());
for (Long id : sortedIds) {
    goodsMapper.reduceStock(id, count);
}

4. 控制事务粒度，严禁在事务里混入 RPC 调用

很多人喜欢在 Spring 的 @Transactional 里发 HTTP 请求或者调用 Redis。 外部接口耗时一旦抖动到 2 秒，这个事务持有的 MySQL 行锁就维持了 2 秒。在并发场景下，持锁时间越长，发生碰撞打成死锁的概率是呈指数级上升的。 原则：事务只包裹纯粹的 DB 写操作，快进快出，毫秒级提交。

老王总结

数据库并发控制，本质上是在数据一致性和吞吐性能之间做平衡。死锁是并发控制中不可避免的产物，MySQL 选择回滚一个事务来解除死锁，本身就是一种自保机制。

我们做架构设计的，不能指望死锁永远不发生，而是要：应用层保持幂等支持重试、代码层规范加锁顺序、隔离层尽量规避间隙干扰。

把底层的因果链想透了，半夜报警响的时候，你才能稳坐钓鱼台。有任何死锁排查的疑难杂症，欢迎在评论区贴日志，老王帮你盘它。