各位，我是老张。今天从一次实战出发，往下拆一层。

周二晚上九点，下单系统的报警群炸了。ERROR 1213刷屏，Deadlock found when trying to get lock。库存服务10分钟攒了一千多条死锁日志，订单创建失败率冲到4%。运维重启实例，症状才消停。我盯着SHOW ENGINE INNODB STATUS的输出，脑子里就一句话：又是库存扣减，又是那两条SQL。

锁这东西，光背四个条件没用。真出事的时候，你得知道锁到底加在哪、按什么顺序加。今天就从这次事故把InnoDB的加锁机制拆开讲。

---

## 一、先说结论

死锁的本质是循环等待。InnoDB的锁加在索引记录上，不是加在逻辑的"行"上。RR隔离级别下，等值查询也会给索引区间加next-key lock。两条SQL只要以不同顺序触碰同一组索引记录，死锁就是迟早的事。

| 关键点 | 说明 |
| --- | --- |
| 锁的落点 | 索引记录，不是表行 |
| 加锁顺序 | InnoDB按索引顺序逐条加 |
| RR等值查询 | 唯一索引命中退化为记录锁，普通索引加next-key lock |
| 死锁条件 | 互斥、持有并等待、不可剥夺、循环等待 |
| 回滚对象 | 检测到死锁后，回滚undo最少的事务 |

这里有个反直觉的点。隔离级别越高，锁越多，死锁越频繁。你越追求"安全"，死锁概率越大，后面压测数据能直接看到。

## 二、事故现场：两条SQL怎么互相卡死的

业务就两个接口。下单扣库存，回补加库存。两个接口都按sku_id定位，加锁顺序却不一样。

```
下单：update t_inventory set stock = stock - 1
      where sku_id in ('sku_1','sku_2','sku_3');

回补：update t_inventory set stock = stock + 1
      where sku_id = 'sku_2';
```

单个看都没毛病。下单一次锁三个sku，回补锁一个。问题出在并发。订单A扣sku_1和sku_2，订单B扣sku_2和sku_1。A先拿到sku_1的锁，B先拿到sku_2的锁。接着A要sku_2，被B占着。B要sku_1，被A占着。谁都不让，循环等待成立。

SHOW ENGINE INNODB STATUS里，LATEST DETECTED DEADLOCK段会把两个事务的锁信息全打出来。一个WAITING FOR这个lock，一个WAITING FOR那个lock。看这段日志，比看报错本身有用得多。

## 三、InnoDB的锁到底加在哪

这个不讲清楚，后面全看不懂。

InnoDB的行锁，本质是索引记录锁。表没有索引，退化成整表锁。有主键，锁加在主键索引上。有二级索引，先锁二级索引的记录，再回表锁主键的记录。

加锁的最小单位是索引记录，不是逻辑上的行。你感觉锁的是同一行，实际可能是主键索引和二级索引两条记录，锁了两个地方。

RR隔离级别下，InnoDB用next-key lock防幻读。next-key lock是record lock加gap lock。gap lock锁索引记录之间的间隙，加锁范围是一个左开右闭的区间。

举个例子。sku_id上有个普通索引，记录值1、5、10、20。`select * from t_inventory where sku_id = 5 for update`在RR下会加next-key lock。先锁住1到5之间的间隙，再锁住值5这一行。组合起来就是区间(1, 5]被锁住，其他事务不能插入sku_id=3的记录，也不能修改sku_id=5的行。

这就是RR下等值查询也锁区间的真相。你以为锁了一行，其实锁了一段。唯一索引等值命中时有优化，next-key lock退化成record lock，只锁命中的那条记录。所以主键等值更新，锁的就是那一行。

## 四、加锁顺序的完整推导

把事务1的加锁轨迹画出来看。

```
事务1: update t_inventory set stock = stock - 1
       where sku_id in ('sku_1','sku_5');

步骤：
1. 走二级索引(sku_id)定位记录sku_id='sku_1'
2. RR下加next-key lock，锁区间(-∞, 'sku_1']
3. 回表，对主键索引记录加record lock
4. 定位下一条记录sku_id='sku_5'
5. 加next-key lock，锁区间('sku_1', 'sku_5']
6. 回表，主键记录加record lock
7. 修改两行stock
8. 事务提交，统一释放
```

注意一个细节。事务2执行sku_id in ('sku_5','sku_1')，InnoDB不会按SQL里的字面顺序加锁，而是按索引顺序。所以两条SQL即使字面顺序反过来，加锁顺序也一样，单条SQL内死不了。

真正会死的，是不同SQL走了不同路径，或者业务代码分两步操作。先锁A再锁B，另一个事务先锁B再锁A。这次事故就是第二种。

## 五、死锁检测机制

死锁靠谁发现？innodb_deadlock_detect，默认开。它维护一张wait-for graph，节点是事务，边表示"在等谁的锁"。每次加锁请求触发检测，沿着图找环。找到环，就回滚其中一个事务，放另一个走。

回滚哪个？InnoDB选undo log最少的事务。改得最少、回滚成本最低的那个。如果两个事务的undo量相同，会优先回滚后加锁的那个。无论选哪个，被回滚的事务都会收到ERROR 1213，业务不重试这条请求就黄了。

压测环境：16核64G，NVMe SSD，MySQL 8.0.32。模拟两个事务交叉更新同一组sku，500并发跑10分钟。

| 隔离级别 | 死锁次数 | 平均TPS |
| --- | --- | --- |
| RR | 47 | 38,000 |
| RC | 3 | 41,000 |

RC下gap lock基本不生效，只锁命中的记录，死锁率掉了一个数量级。代价是可能幻读，业务得自己兜底。

死锁检测本身也有开销。每次加锁都扫一遍等待图。

| 配置 | 平均TPS | 检测CPU占用 |
| --- | --- | --- |
| 默认开启 | 38,000 | 约8% |
| 关闭检测 | 41,000 | 约2% |

关闭检测后没有1213了，死锁不会被主动发现。锁等待会硬拖到innodb_lock_wait_timeout（默认50秒）才超时报错。省了检测的CPU，但请求要挂50秒，连接池可能被占满，这条路上线前得想清楚。

## 六、解法：架构决策框架

从事故里总结，方案按成本从低到高排。

第一，统一加锁顺序。所有改库存的地方，先把sku_id排序再按序加锁。全局顺序一致，循环等待就断了。这是根治，成本最低。这次事故最后就是这么改的。

第二，收窄锁的覆盖范围。能用唯一索引定位就别扫区间，能走主键就走主键，把next-key lock的范围压到最小。

第三，降隔离级别。业务允许就把RR降到RC，gap lock消失，死锁率断崖式下跌，代价是幻读自查。

第四，业务侧重试。死锁是常态不是异常。把1213当正常情况，捕获后重试两三次。配合固定顺序加锁，影响基本抹平。

| 场景 | 推荐做法 |
| --- | --- |
| 下单/库存核心链路 | 固定顺序加锁 + 重试 |
| 高并发读多写少 | 降RC，锁只加在命中行 |
| 批量更新 | 一次锁全量，别分批 |
| 报表/长事务 | 别开长事务，持锁时长决定冲突窗口 |

## 七、踩过的坑

最早一次死锁，我盯SHOW ENGINE INNODB STATUS只盯着两个事务的SQL，死活看不出哪锁哪。后来把LOCK WAIT段连同索引名一起看，才发现是二级索引和主键索引两条锁链交叉。纯粹加锁顺序问题。这个排查习惯留到现在。

还有一个坑。业务以为"先查再改"能避免死锁，先select出来排个序再按序update。结果select默认不加锁，两个事务同时查到同一批sku，再各自update，顺序还是乱的。真要控制顺序，要么直接排序update，要么select加for update。这个我搞错过，线上踩完才反应过来。

迁移的时候也容易踩。国产数据库的死锁检测开关、日志格式跟MySQL不完全一样，别拿MySQL的排查思路硬套。我之前切库后按老习惯找LATEST DETECTED DEADLOCK，日志结构对不上，排查浪费了半天。参数名和报错关键字都得先验证一遍再上线。

## 结语

死锁不神秘，就是加锁顺序不一致造成的循环等待。InnoDB把锁加在索引记录上，RR下还锁区间。理解加锁顺序，比背死锁四条件有用得多。

后来我从Java后端转做架构，就是因为这类问题。应用层的try-catch救不了数据库层的锁，你得走到内核那一层去看。

各位生产环境有没有被死锁坑过？用的什么解法？一起聊聊。

我是底层玩家老张。咱不聊概念，只聊源码和压测跑出来的东西。


周二晚上九点，下单系统的报警群炸了。ERROR 1213刷屏，Deadlock found when trying to get lock。库存服务10分钟攒了一千多条死锁日志，订单创建失败率冲到4%。运维重启实例，症状才消停。我盯着SHOW ENGINE INNODB STATUS的输出，脑子里就一句话：又是库存扣减，又是那两条SQL。

数据库死锁怎么根治？从InnoDB加锁顺序推导到压测验证的完整复盘

从一次库存扣减死锁事故出发，拆解InnoDB行锁、间隙锁与next-key lock的加锁顺序，推导死锁检测与回滚选择，附隔离级别与死锁检测的压测数据

数据库

架构设计

后端

MySQL死锁实战解析：库存系统ERROR1213事故复盘，深入InnoDB加锁机制与next-key lock原理。从加锁顺序、索引记录锁到死锁检测机制全面拆解，提供统一排序加锁、降低隔离级别等解决方案，附压测数据对比，助你快速定位并解决生产环境死锁问题。

代码解释

MySQL

Java

腾讯云BI特惠9.9元起！


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

数据库死锁怎么根治？从InnoDB加锁顺序推导到压测验证的完整复盘-腾讯云开发者社区-腾讯云

数据库死锁怎么根治？从InnoDB加锁顺序推导到压测验证的完整复盘

数据库死锁怎么根治？从InnoDB加锁顺序推导到压测验证的完整复盘

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐