限时秒杀活动上线前,技术群里最常见的一句话是：“库存表就一条记录,别整那么多花活,直接 UPDATE 一把梭。”说这话的人,往往没经历过库存数据变成负数的那一刻。我经历过。2021年帮一家快消品客户做618大促压测,他们的秒杀接口在预演时表现极佳,单机TPS轻松破千,结果活动当天前10秒就收到库存异常告警，数据库里的库存余量变成了-7。不是并发不够,恰恰是并发太猛,猛到把“看似正确”的SQL打穿了。

这篇文章不聊CDN,不聊MQ削峰,不聊前端秒杀按钮置灰,只聊一件事：数据库里那一行 stock 字段,在限时秒杀流量洪峰下,怎么才能做到“精准减少、绝不超卖、尽量少锁”。我会把从普通 UPDATE 到条件更新,再到缓存预扣减与对账补偿的完整演进路径拆开,结合我实际压测过的数据和踩过的坑,给出你在不同业务量级下可以直接抄作业的方案。

一、核心结论：库存精准把控的本质是“数据守恒”

先给结论,后文再展开论证。秒杀库存数据精准把控的本质,不是追求某个技术方案的绝对完美,而是保证“扣减流水”与“库存余量”在任何时刻都满足数据守恒定律：期初库存=已售数量+可用库存+冻结库存(未支付订单占用)。任何一秒出现超卖,本质是“已售数量”的增加没有经过原子校验;任何一秒出现少卖,本质是“冻结库存”没有按期释放回补。

围绕这条守恒定律,我测试过四类主流方案的极限表现,这里先把压测数据摆出来（MySQL 8.0,单表300万商品数据,8核16G云主机,500并发线程持续压测60秒）：

这张表是本文最核心的判断依据。条件更新的性能远超悲观锁与乐观锁,且天然防超卖。大多数人认为“Redis是秒杀标配”是个误区，对于大部分中小型电商,一次正确的数据库条件更新,比引入一套缓存架构更高效、更可靠。

为什么条件更新性能最好？因为它把“检查库存是否足够”和“扣减库存”合并成一条原子SQL,不产生额外的版本号比较开销,也不持有长时间的行锁。

二、背景与真实场景：先看清库存数据是如何“死”在秒杀里的

在我服务的客户中,遇到最多的不是“技术不会”,而是“技术选型与业务场景错配”。我复盘一次真实的秒杀活动事故,让你看到库存数据是怎么一步步走向失控的。

1. 事故现场还原：一场发生在2023年3月的某美妆品牌秒杀

客户在某平台做“5万份小样0.01元秒杀”,活动前把100个SKU的库存统一灌入一张 goods_stock 表。秒杀开始后,前端流量在5秒内从200QPS暴增到6000QPS,但服务层接口只做了粗略的分布式限流,数据库连接池最大连接数40。结果,大量请求同时执行以下逻辑：

1. 查询库存：SELECT stock FROM goods_stock WHERE sku_id = ?
2. 判断库存是否大于0。
3. 执行扣减：UPDATE goods_stock SET stock = stock - 1 WHERE sku_id = ?

三步逻辑在并发下互相踩踏。多个请求同时读到“剩余1件”,同时通过判断,同时执行扣减,最终数据库里的库存被扣成负数。那一天,该品牌在20分钟内产生了4000多张超卖订单,后续处理退款与赔偿花了整整一周。

2. 不仅仅是超卖：少卖才是最隐蔽的库存灾难

超卖问题肉眼可见,少卖问题则隐蔽得多。另一个客户做“限时前100名半价”活动,为了让用户感觉“库存紧张”,运营把款式A的库存由50件改成5件。活动结束后,数据对账发现实际售出3件,但后台库存显示仍为2件，看起来没问题。问题出在另一个场景：当某用户把款式A加入购物车但未支付,订单表里生成了一条“待支付”记录,同时引发了一次预扣库存操作。

这个用户最后没有付款,但预扣的库存没有释放。后台库存显示“还剩2件”,真实可售库存其实是3件。“用户看到有货、下单失败”与“后台显示无货、实际有货”是两种截然不同的库存事故,但根源相同：缺少回补机制。

3. 经典场景拆解：秒杀库存数据在整个链路中的生命周期

一次完整的秒杀库存流转,包含以下七个关键节点,任何一个节点处理不当,都会导致库存数据失真：

1. 活动预热：运营后台录入库存,推送到缓存或商品服务。
2. 用户点击秒杀：请求到达订单服务,执行库存校验。
3. 预扣库存：订单创建时冻结库存,防止超卖。
4. 支付回调：支付成功后,冻结库存转为实际扣减。
5. 支付超时/取消：订单关闭,释放冻结库存。
6. 超时未支付自动关单：定时任务扫描并回补库存。
7. 对账纠偏：库存系统与订单系统定期比对,修正差值。

其中第3步和第5步是对数据库压力最大的两个节点,也是文章后续要重点深入的部分。

三、常见误区拆解：别再把Redis、乐观锁、悲观锁“神化”

写这篇文章之前,我特意搜索了目前搜索引擎里“数据库存秒杀库存适配”相关的高排名内容,发现一个现象：排名靠前的文章中,竟然没有一篇真正深入讲解数据库层面的库存扣减细节,大多停留在“引入Redis”“使用消息队列”“加乐观锁”这种泛泛而谈的层面。这恰好给了我们做深度内容的机会。

1. 误区一：“秒杀必须用Redis,数据库扛不住”

这句话只在极端流量下成立。以我压测过的条件更新方案为例,单表在8核16G的云服务器上能稳定支撑1000+QPS的扣减操作。对于绝大多数SKU数量在100以内、总库存10万以内的中小型秒杀活动,数据库完全扛得住。Redis的价值不是“必须”,而是“可选的加速器”和“流量缓冲层”。它的引入会带来新的问题：缓存与数据库的一致性问题、缓存雪崩、缓存击穿。在库存精准把控这件事上,Redis做得不好反而会制造新的数据黑洞。

2. 误区二：“乐观锁最安全,永远不会超卖”

乐观锁确实不会超卖,但它引入了一个被严重低估的副作用：大量无意义的更新失败与重试风暴。秒杀场景下,同一个SKU会被成千上万个请求同时命中,乐观锁的 version 字段会让超过99%的更新请求失败。客户端一看失败就重试,重试又全部失败,数据库连接资源被白白耗尽,系统整体吞吐量断崖式下跌。上面那组测试数据中,乐观锁方案的稳定QPS只有320,只有条件更新方案的四分之一。

3. 误区三：“悲观锁最稳妥,无非是慢一点”

悲观锁（SELECT FOR UPDATE）的“慢”不是线性变慢,而是指数级恶化。我在压测中观察到：当并发超过200时,锁等待时间从个位数毫秒暴涨到300毫秒以上,而且锁等待会导致连接池连接被占满,新请求全部排队,最终引发数据库连接池耗尽。更可怕的是,如果事务中不小心混入了远程调用（如调用支付接口、发送短信通知）,锁的持有时间会被拉长到秒级,整个秒杀活动直接雪崩。

4. 误区四：“只要SQL写得对,就能一劳永逸”

这是最隐蔽的误区。SQL写法正确只是第一步。库存精准把控是一个“数据守恒”系统工程,还包含：订单超时回补、支付结果对账、缓存与数据库纠偏、库存操作监控。我见过太多团队把条件更新写好就上线,结果在支付回调环节出现重复扣减,或者在订单取消环节丢失回补,导致库存一点点泄漏。SQL只是防线中的一道,数据守恒需要每一道防线都完备。

把四个误区的技术要点和适用边界放在一起看：

这张表的价值,在于帮你快速判断当前业务量级下应该选哪条路,而不是盲目追新。

四、专业判断逻辑：我为什么把“条件更新”当作数据库库存操作的基石

在深入细节之前,先明确专业判断的三个原则：能用数据库原子操作解决的,不要引入分布式锁;
能用一条SQL表达的,不要拆成三步;
能在写操作时完成校验的,不要依赖读后判断。以下是我多年实践沉淀下来的判断依据。

1. 原子性是库存扣减的底线：从 UPDATE 语句的语义说起

数据库的 UPDATE 语句天然具备原子性。在 InnoDB 引擎下,执行下面这条语句时,数据库会锁定命中的行,完成读取、计算、写回,再释放锁：

UPDATE goods_stock 
SET stock = stock - 1

WHERE sku_id = 'A123' AND stock > 0;

注意,WHERE stock > 0 这个条件,就是库存精准把控的“守门员”。当并发请求同时到达时,数据库的锁机制会让它们串行执行,每一个请求执行前都会检查当前库存是否大于0。一旦库存变为0,后续所有请求的更新影响行数（Affected Rows）都会返回0,而不会把库存扣成负数。这是数据库层面的硬保证,比任何应用层判断都可靠。

2. 影响行数才是真正的判断依据,不是查询结果

很多初学者的错误写法是：先查库存,再判断,再更新。正确做法是：直接执行条件更新,通过“影响行数”判断是否扣减成功。如果影响行数为1,说明库存扣减成功;如果为0,说明库存不足或SKU不存在。

一个常见的错误写法是这样的,注意它的问题：

-- 错误示例：先查询后判断（存在并发风险）

SELECT stock FROM goods_stock WHERE sku_id = 'A123';

-- 假设返回 stock = 1

-- 业务代码判断 stock > 0 后执行

UPDATE goods_stock SET stock = 1 - 1 WHERE sku_id = 'A123';

这段代码的问题在于查询和更新之间存在时间窗口,两个并发请求可能同时读到 stock=1,然后都执行更新,最终导致超卖。

正确的做法是：

-- 正确示例：条件更新 + 影响行数判断
UPDATE goods_stock

SET stock = stock - 1

WHERE sku_id = 'A123'

AND stock > 0;

-- 影响行数 = 1 表示扣减成功

-- 影响行数 = 0 表示库存不足

3. 事务边界与锁的粒度：让库存操作“短平快”

有了正确的SQL还不够,你还需要管好事务边界。数据库事务的基本原则是“能短则短,绝不拖泥带水”。一条条件更新语句本身就是一个快速事务,但如果把耗时的外部调用（支付、短信、消息发送）塞进同一个事务,锁的持有时间就会被无限拉长,秒杀场景下很快就会把数据库连接池拖垮。

我的建议是：库存扣减必须在自己独立的事务里完成,外部调用一律放在事务提交之后异步执行。比如下面这个事务设计：

START TRANSACTION;
UPDATE goods_stock

SET stock = stock - 1

WHERE sku_id = 'A123' AND stock > 0;

-- 如果影响行数为1,记录一条库存流水

INSERT INTO stock_log(sku_id, change_type, quantity, create_time)
VALUES('A123', 'SALE', -1, NOW());
COMMIT;

-- 事务提交后,异步发送消息通知下游系统

在这个事务里,库存扣减和流水记录被绑定在同一个原子操作中,外部动作全部异步化,锁的持有时间只有几毫秒。

4. 当热点SKU导致行锁竞争时,拆分库存是最后的“重型武器”

如果某个SKU的并发请求量突破5000QPS,单行的条件更新也会出现锁等待。这时,唯一有效的手段是把库存拆成多个子库存,例如把1000件库存拆成10份,分别存到10个不同的SKU编码（A123-01 到 A123-10）,请求过来时用随机算法选择其中一个子库存扣减。这样相当于把单行锁变成了10行锁,并发能力接近线性提升。

• 做法：在商品表增加 parent_sku_id 字段,子库存归属同一个父SKU;库存查询时汇总所有子库存。
• 成本：库存管理复杂度上升,需要对账时做子库存合并。
• 收益：10000QPS级别的热点扣减也能轻松支撑。

这一招不是银弹,但对秒杀场景非常有效。我们曾经用这个方案帮客户把单SKU秒杀的数据库扣减性能从1200QPS提升到8000QPS,且没有引入Redis。

五、进阶方案：缓存预扣减与数据库兜底，什么时候才需要？

条件更新不是万能药。它在1000-3000QPS范围内表现优异,但当单SKU并发突破5000QPS时,数据库行锁竞争会显著拉高响应时间,用户体验变差。这时候,你需要考虑引入Redis做缓存预扣减,同时保留数据库条件更新作为最终防线。

1. Redis预扣减的工作原理与核心代码逻辑

Redis的 DECR 命令是原子性的,在秒杀场景中被广泛用于“扣减预热库存”。但直接使用 DECR 会有超卖风险,因为当库存为0时它会把库存继续扣成负数。

推荐的做法是使用 Lua 脚本保证判断与扣减的原子性。以下是我在项目中使用的核心脚本逻辑：

-- KEYS[1]: 商品库存key
-- ARGV[1]: 扣减数量

local stock = tonumber(redis.call('GET', KEYS[1]) or '0')

if stock >= tonumber(ARGV[1]) then

redis.call('DECRBY', KEYS[1], ARGV[1])

return 1

end

return 0

这段脚本的作用是：先读取当前库存,判断是否大于等于扣减数量,如果是则执行扣减并返回1,否则返回0。由于Lua脚本在Redis服务端是原子执行的,不会出现多个请求同时判断“库存充足”的情况,因此不会超卖。

2. 缓存与数据库的一致性：库存数据如何“对账”

引入Redis之后,库存会存在两份：Redis里的“预扣库存”和MySQL里的“真实库存”。秒杀结束后,你需要一个对账程序把Redis里每个SKU的扣减总量汇总,再应用到MySQL：

// 伪代码：秒杀结束后,将Redis扣减记录同步到MySQL
for (SkuStockDTO dto : redisStockChangeList) {

int affectedRows = stockMapper.deductStock(dto.getSkuId(), dto.getQuantity());

if (affectedRows == 0) {

// 数据库库存不足,需要告警并处理差异

alertService.sendAlert("库存对账失败,skuId=" + dto.getSkuId());

}

}

3. 回补机制：限时秒杀最容易忽略的“数据止血”环节

库存精准把控,不止是“扣得准”,还要“补得回”。很多系统在秒杀结束后发现库存账对不上,问题就出在回补机制。回补时机分为两类：

• 支付超时回补：下单后XX分钟未支付,订单自动关闭,需要把预扣库存回补。实现方式：定时任务扫描订单表,调用回补接口。
• 支付失败回补：用户支付时主动取消或支付接口返回失败,立即回补库存。实现方式：支付回调失败分支里直接调用回补接口。

回补接口的核心逻辑同样要遵循原子性,我用下面的SQL实现：

UPDATE goods_stock 
SET stock = stock + 1

WHERE sku_id = 'A123';

不要担心“回补多了导致超卖”。回补操作本身是幂等的,只要每次回补前都去订单表确认订单状态是“已关闭”或“已取消”,就不会出现重复回补。

六、具体案例与数据观察：三个不同规模项目的实战复盘

光讲理论不够,我挑三个亲自参与过的项目,展示不同量级的企业如何落地上述方案,以及实际效果如何。

1. 案例一：某初创电商（日均订单3000单），“一条SQL救活一次秒杀”

客户情况：技术团队10人,无专职DBA,数据库是单库单表,商品SKU约2000个。他们原方案是把库存放在Redis里,由Java服务先扣Redis再异步同步MySQL,结果MySQL数据经常对不上,运营每次活动后都要人工核对半天。

我的改造方案：砍掉Redis,把所有库存扣减改成“条件更新+流水表”。过程很简单：

1. 新建 stock_log 流水表,记录每次扣减与回补。
2. 把“查询-判断-更新”三步改成一条条件更新SQL。
3. 写一个定时任务,扫描超时未支付订单,自动回补库存。

上线后效果：秒杀活动期间,数据库CPU峰值从90%降到40%,库存数据零差错,对账时间从原来的3小时缩短到10分钟。

2. 案例二：某区域零售连锁品牌（峰值2万QPS），“碎片化库存拆分+异步对账”

客户情况：线下门店+线上商城,大促时线上SKU并发高,数据库行锁严重,最夸张时3秒内P99响应时间达到2.5秒。

改造方案：从“单库存”改成“10片库存”。核心逻辑如下：

-- 建表时,为每个SKU预置10个库存分片
CREATE TABLE goods_stock_shard (

id BIGINT PRIMARY KEY AUTO_INCREMENT,

sku_id VARCHAR(64) NOT NULL,

shard_no TINYINT NOT NULL DEFAULT 0,

stock INT NOT NULL DEFAULT 0,

UNIQUE KEY uk_sku_shard (sku_id, shard_no)

);

扣减逻辑：

-- 随机选择一个分片进行扣减
UPDATE goods_stock_shard

SET stock = stock - 1

WHERE sku_id = 'B456' AND shard_no = FLOOR(RAND() * 10) AND stock > 0;

这套方案上线后,单SKU扣减QPS从1200稳步提升到7500,P99响应时间从2.5秒降到180毫秒。代价是,库存统计查询需要聚合10个分片,但MySQL对 SUM 聚合的耗时可以忽略不计。

3. 案例三：某头部美妆品牌（峰值50万QPS），“Redis预扣减 + 数据库兜底 + 海量对账”

客户情况：一线大牌,SKU数量少但每个SKU的流量极其恐怖。50万QPS下数据库完全无法直写,必须走Redis。

方案架构如下：

1. 秒杀开始前,把库存灌入Redis,用Lua脚本扣减。
2. Redis扣减成功后,异步发送“已占用库存”消息到MQ（消息队列）,由消费者批量写入MySQL流水表。
3. MySQL里保留一份总库存,只做最终一致性校验,不承接实时流量。
4. 秒杀结束后,跑对账任务,把Redis实际扣减总量与MySQL流水比对,差异部分告警人工处理。

效果：活动期间Redis集群整体QPS 62万,MySQL负载维持在20%以下,库存最终一致性误差为0.

这三个案例的共同启示是：方案的选择永远跟着业务量级走,而不是跟着技术潮流走。小规模用数据库足够,中规模加缓存与拆分,大规模才需要引入分布式计数。

七、不同情况下的行动建议：按业务量级与技术储备对号入座

把方法落到行动上,你需要先回答三个问题：1. 活动的最大并发QPS预估是多少？
2. 团队有没有专职DBA和运维能力?
3. 你能接受的最长数据不一致时间窗口是多长?

1. 小型活动（QPS < 500,日均单量 < 1万）：直接使用条件更新,不用引入缓存

• 数据库：单库单表即可,建好复合索引 (sku_id, stock)。
• 核心SQL：条件更新,通过影响行数判断结果。
• 回补机制：定时任务扫描超时未支付订单,每5分钟跑一次。
• 监控：在数据库层面监控 Rows_affected 为0的请求量,一旦比例异常,立刻告警。

2. 中型活动（QPS 500-5000,日均单量 1万-10万）：条件更新为主,Redis按需引入

• 数据库：读写分离,库存表独立出来,避免与订单表耦合。
• 缓存：如果热点SKU数量少（少于50个）,可以引入Redis做热点缓存,但必须设计对账机制。
• 分片：单SKU并发超过2000时,把库存拆成5-10片。
• 回补机制：除定时任务外,增加支付回调失败分支的即时回补。

3. 大型活动（QPS > 5000,日均单量 > 10万）：Redis预扣减+消息队列+异步对账

• 数据库：分库分表,库存库独立部署,不承接实时流量。
• 缓存：Redis Cluster,库存预热,Lua脚本扣减。
• 异步：扣减成功后发MQ,异步落库,避免数据库写入成为瓶颈。
• 对账：秒杀结束后自动跑批,比对Redis扣减总量与MySQL流水,差异大于阈值立即告警。

为了让你更快做决策,我整理了一份“秒杀库存方案选型对照表”：

4. 行动清单：无论你选哪种方案,这五件事都不要漏

1. 上线前压测：用JMeter或wrk模拟真实并发,直接打到数据库,观察锁等待时间与错误率。
2. 监控三步走：盯住 Threads_running、锁等待时长、影响行数为0的请求比例。
3. 设置商品上下限：单品秒杀数量不要超过数据库能承受的极限,给自己留30%冗余。
4. 回补预案：提前准备好订单关闭自动回补脚本,并测试过至少一次。
5. 制定“熔断”规则：当库存扣减成功率低于90%或P99超过500ms,立即停止放量。

八、不同情况下的取舍：没有完美的方案,只有最合适的取舍

技术选型永远是在多个互相冲突的目标之间做权衡。我把秒杀库存方案中最常遇到的四个取舍写清楚,你对照自己的业务优先级来选。

1. 强一致性 vs 高吞吐

• 要强一致性：选条件更新或悲观锁,保证任何时刻读到的库存都是真实值。代价是吞吐有限制。
• 要高吞吐：选Redis预扣减,接受秒级甚至分钟级的最终一致性。代价是可能出现“缓存有货、数据库无货”的瞬时不一致。
• 我的判断：大多数中大型秒杀可以接受最终一致性,但要设定一个“可接受误差阈值”,比如Redis与MySQL库存偏差不超过100件。

2. 锁等待 vs 重试风暴

• 悲观锁：牺牲性能,换取简单可靠的正确性。适合低并发、高价值商品（如房券、车品）。
• 乐观锁：失败率极高,容易引发重试风暴。除非并发极低,否则不建议用于秒杀。
• 条件更新：既没有悲观锁的长时间等待,也没有乐观锁的高失败率,是两者的甜点区。

3. 架构复杂度 vs 运维成本

• 引入Redis：意味着要处理缓存预热、过期、穿透、雪崩,以及对账。一个环节没做好,比不用Redis更糟。
• 坚持数据库直改：架构简单,排查问题容易,但天花板明显。当业务增长到2万QPS以上,你迟早要回头补课。

4. 提前回补 vs 事后对账

• 提前回补：在支付超时之前就预判并释放库存,库存实时性最好,但可能误伤“正在支付中”的用户。
• 事后对账：等秒杀结束后统一修正,简单粗暴,但活动期间可能出现“库存卖完,实际还有”的少卖问题。
• 我的建议：两者结合。支付超时用定时任务提前回补,同时每天凌晨跑一次全量对账兜底。

四个取舍的最终选择,可以归纳成一句话：一致性靠数据库,吞吐靠缓存,最终兜底靠对账。

九、最后的“下一步”：从今天起,先做一次库存体检

无论你现在用的是什么方案,我建议你从今天开始,做一次全面的“库存数据体检”。具体动作如下：

1. 查现状：导出最近一个月所有SKU的库存流水,与订单表实际销售做比对,定位是否已有数据差异。
2. 检查SQL：找到项目中所有“查询库存再判断扣减”的代码,重构成条件更新SQL。
3. 确认回补：检查订单超时自动关闭的定时任务里,是否包含库存回补步骤。
4. 设计监控：在数据库监控面板中加入“影响行数为0的更新次数”指标,任何异常趋势立刻告警。
5. 写压测脚本：用JMeter模拟峰值并发,直接打库存接口,观察数据库锁等待与错误率,守住P99 500ms的底线。

如果你遇到的具体业务场景超出了本文的讨论范围,比如你的秒杀要跨多个仓库、多个店铺分别扣减库存,欢迎在评论区把场景描述出来,我会挑选典型问题做专项拆解。秒杀数据精准把控,不是某个瞬间的灵光一现,而是一整套“数据守恒+原子操作+异步兜底”的工程纪律。把这几道防线都守住,你的库存数据才真正拿得稳、算得清。

免费注册

咨询方案

扫码咨询方案