
大家好，我是数据库小学妹👋 我踩过的坑，你别再踩。

去年大促的零点，我盯着大屏看订单曲线往上冲，心里挺美。二十分钟后，客服群里有人问，同一个商品怎么卖了 137 件，库存明明只有 100。我第一反应是不可能。库存扣减是包在事务里的，事务还能出错？

后来把日志摊开，一条条对下来。问题不在事务，在事务里面那几行代码的先后顺序。

## 先说清楚，超卖到底是怎么发生的

我用最典型的那种写法复现了一次。逻辑是"先查库存，再判断，再扣减"。

```java
// 应用层写法：看着天衣无缝，其实中间有个致命的空隙
@Transactional
public void deduct(Long productId) {
    Product p = mapper.selectById(productId);          // 1. 查
    if (p.getStock() < 1) {                            // 2. 判断
        throw new BizException("库存不足");
    }
    mapper.updateStock(productId, p.getStock() - 1);   // 3. 扣
}
```

三步，看着没问题。但第 1 步和第 3 步之间，是有时间的。假设库存只剩 1 件，两个线程同时进来。它们都读到 1，都判断通过，都去扣。库存就变成了 -1。

更麻烦的是，MySQL 默认的 RR 隔离级别下，`selectById` 走的是快照读。它读到的可能压根不是最新值。你就算把事务加上，也不会让这两步变成一个原子操作。事务保证的是要么全成功、要么全失败。它不保证这两步之间没人插进来。

这一点我搞混过很久。刚转行那阵子我一直以为，加了 `@Transactional` 就等于锁上了。其实事务只是给你划了个边界。边界里面有没有并发问题，得看你自己的操作是不是原子的。

## 真正原子的写法，其实只有一行

MySQL 的 UPDATE 有个特性，很多人没注意到。它是当前读，会去读最新的数据，同时给命中的行加排他锁。判断和修改都在这把锁里面完成。

```sql
-- 把"判断"和"扣减"塞进同一条 UPDATE
UPDATE product
SET stock = stock - 1, updated_at = NOW()
WHERE id = 1001
AND stock >= 1;
```

应用层只需要看一个返回值，`affected_rows`。它返回 1，说明扣减成功。返回 0，说明 `stock >= 1` 没满足，库存已经没了，直接告诉用户抢光了。整个过程没有空隙，因为判断和修改发生在同一条语句、同一把锁里。

```java
int rows = mapper.deductAtomic(productId);
if (rows == 0) {
    throw new BizException("库存不足");
}
```

就这一行 SQL，把我那次事故的根因堵死了。我当时的第一反应是，那还要分布式锁干嘛。这个问题值得展开说说。我现在的判断是，单行库存的扣减用不上分布式锁。分布式锁解决的是跨资源、跨库的互斥，比如"一个用户不能在两个节点同时下单"，这种拿不到共享数据结构的场景。单行库存本身就在数据库里，行锁就是现成的互斥手段。你在行锁外面再套一层 Redis 锁，等于上了把更慢的锁，还额外引入锁超时、锁续期这一堆新问题。

## 但热点行会卡住，这一步绕不开

原子 UPDATE 解决了正确性，没解决性能。所有请求都去抢同一行的锁，只能排队。库存只剩 100 件的时候无所谓。库里 10 万件、几十万人在抢的时候，这一行就是瓶颈。

我当时也去查过，这个瓶颈是硬的，调参绕不过去。一条单行 UPDATE 能扛多少 QPS，取决于硬件、事务大小、刷盘配置。别人的数字我不确定，反正我们自己压出来的结果，远低于预期。

后来用了个很土但有效的办法，把库存分桶。

```sql
-- 一行热点拆成 N 行，总库存 = SUM(stock)
CREATE TABLE stock_bucket (
    product_id BIGINT  NOT NULL,
    bucket_no  TINYINT NOT NULL,
    stock      INT     NOT NULL,
    PRIMARY KEY (product_id, bucket_no)
);

-- 扣减时，挑一个桶去扣
UPDATE stock_bucket
SET stock = stock - 1
WHERE product_id = 1001
AND bucket_no = 7
AND stock >= 1;
```

原理很简单。十个桶就是十行，十行就是十把锁，并发度直接上去。代价是逻辑变复杂。你要处理某个桶扣空之后换桶，要能算出总库存，退款归还的时候还得知道还回哪个桶。

这里有个坑我踩过，桶不是越多越好。桶多了，总库存的误差和归还的复杂度都会上来。我们最后用十到二十个，具体看单品的抢购规模，没有通用数字。

## 把这些方案摆在一起看

| 方案 | 会不会超卖 | 性能上限 | 复杂度 | 适合什么场景 |
| --- | --- | --- | --- | --- |
| 先查后改 | 会 | 高 | 低 | 任何并发场景都不该用 |
| 原子 UPDATE | 不会 | 受单行锁限制 | 低 | 中小规模抢购，首选 |
| 分桶库存 | 不会 | 高 | 中 | 单品抢购量很大 |
| Redis 预扣 + 异步落库 | 不会，但要处理补偿 | 最高 | 高 | 超高并发，且能接受最终一致 |
| 分布式锁 | 不会 | 低 | 中 | 单行库存用不上，跨资源才需要 |

Redis 预扣这条路我列进去了，但我们最后没上。不是它不好，是当时的量还没到。它能扛住最高的并发，代价是把一致性推给了补偿逻辑。预扣成功、落库失败怎么办，Redis 挂了怎么恢复，超时未支付怎么归还，每一个都是新的事故面。我没把握把这几条补偿都做对，所以先用分桶，量真上来了再说。

## 还有一层，隔离级别和索引会改变锁的范围

这是我在压测里才发现的。同样是扣库存，走得通的路不一样，锁的范围差很多。

如果 `WHERE` 走的是主键等值或者唯一索引等值，比如 `id = 1001`，那它在 RR 下加的是行锁。只锁这一行，并发影响可控。

如果条件走的是普通索引，比如按活动 ID 批量扣减，写法是 `WHERE activity_id = 5 AND stock >= 1`。那加的就是 next-key lock，会把 `activity_id = 5` 范围内的行和间隙一起锁上。并发一上来，锁等待和死锁就都来了。

这条我原来一直没太在意。直到压测里出现连片的锁等待超时，我才回头去翻 `information_schema.innodb_trx`，把每个事务锁了哪些行一条条对出来。

还有个组合场景要小心。一次下单要扣两个商品的库存。事务 A 先锁商品 1 再锁商品 2，事务 B 反过来，两边就会互相等。解法很土，统一按商品 ID 从小到大排序，再依次扣。

顺带提一句，这套逻辑在不同隔离级别下表现也不一样。RC 对不匹配的行会提前放锁，锁范围比 RR 小。我后来把扣库存的那几个接口单独确认了一遍隔离级别，不再让它跟着全局配置走。

## 避坑清单

`stock` 字段设成 UNSIGNED 有用，但我见过有人把它当唯一防线。它确实能兜住最后一步。在严格模式下，扣到 0 再减会直接报错、事务回滚，不会真的变成负数。可这个报错来自数据库，不来自你的业务逻辑，用户看到的是一句看不懂的异常。它该是兜底，不该是唯一一道。

库存归还比扣减更容易出事。订单取消、超时未支付、退款，每条路径都要还库存。我见过一次重复归还，就是退款接口重试了两次。归还的接口得带幂等键，或者落一张归还流水表，靠唯一索引拦住重复。

压测别只压成功路径。我们第一次压测跑得很漂亮，超卖为零。后来才发现压的全是库存充足的情况，压根没进到 `affected_rows = 0` 那条分支。库存不足时的返回、扣减失败后的重试、以及重试会不会把热点放得更大，都得单独压一遍。

## 写在最后

这次事故之后，我把一句话写进了我们的评审清单。**数据库负责库存逻辑的最后一道正确性，但它不负责扛下所有性能。** 这两件事经常被混在一起，混在一起就会出事。要么为了正确性，把并发都砸到数据库上硬扛；要么为了性能，把正确性让出去。

我现在的顺序是，先保住正确。用一条原子 UPDATE 把根因堵死，压测看量，量不够再谈分桶，还不够再谈 Redis。至于分布式锁，那是给跨资源场景准备的，不是给单行库存准备的。

你们大促的库存是怎么扣的？踩过超卖的坑吗？评论区聊聊。

我是数据库小学妹，帮你少走弯路少踩坑，咱们下篇见👋


去年大促的零点，我盯着大屏看订单曲线往上冲，心里挺美。二十分钟后，客服群里有人问，同一个商品怎么卖了 137 件，库存明明只有 100。我第一反应是不可能。库存扣减是包在事务里的，事务还能出错？

大促超卖37单之后：库存扣减的原子UPDATE、分桶与锁范围实战复盘

从一次大促超卖事故切入，拆解"先查后改"为什么会在并发下超卖、原子 UPDATE 的当前读与行锁原理、热点行的分桶拆解方案、Redis 预扣的一致性代价，以及隔离级别和索引类型如何影响锁范围，最后给出库存扣减的正确性优先顺序。

数据库

后端

架构设计

超卖根因是"先查后改"存在时间间隙，单行UPDATE原子扣减可堵死漏洞，行锁保障正确性但热点行是瓶颈，分桶提升并发度，锁范围受隔离级别影响，归还需幂等，压测要覆盖失败路径。

数据结构

代码解释

MySQL

Redis

腾讯云数据库特惠，新用户首单0.5折起


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

大促超卖37单之后：库存扣减的原子UPDATE、分桶与锁范围实战复盘-腾讯云开发者社区-腾讯云

大促超卖37单之后：库存扣减的原子UPDATE、分桶与锁范围实战复盘

大促超卖37单之后：库存扣减的原子UPDATE、分桶与锁范围实战复盘

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐