MySQL 热点库存行架构演进：从单行扣减到分桶库存

库存扣减看起来只是一个简单的 UPDATE，但在高并发场景里，它很容易变成 MySQL 的热点行问题。所有请求都抢同一行库存，最终表现不是 CPU 先满，而是行锁等待变长、接口排队、连接池被拖住。

这篇文章按“规模化架构深挖”的方式，拆一条库存扣减链路的演进过程：先看单行库存为什么撑不住，再看分桶库存怎样把锁压力摊开，最后讨论它带来的汇总校验、超卖边界和上线验证。目标不是把方案神化，而是说清什么时候值得引入这类复杂度。

规模背景：大促下所有请求都打到一行

假设商品表里用一行保存某个 SKU 的库存：

CREATE TABLE sku_stock (
  sku_id BIGINT PRIMARY KEY,
  available INT NOT NULL,
  updated_at DATETIME NOT NULL
) ENGINE=InnoDB;

扣库存 SQL 通常会写成这样：

UPDATE sku_stock
SET available = available - 1,
    updated_at = NOW()
WHERE sku_id = 10001
  AND available > 0;

这条 SQL 的好处是简单：条件里直接防止库存扣成负数，受影响行数为 1 表示扣减成功，为 0 表示库存不足。但在大促场景里，问题也很明显：10 万个请求不是分散写 10 万行，而是集中更新 sku_id = 10001 这一行。

当并发上来后，InnoDB 对同一行更新会排队。每个事务都要等前一个事务提交后才能继续，队伍一长，应用侧就会看到接口耗时抬升、连接占用时间变长，甚至出现锁等待超时。

原架构瓶颈：单行扣减把并发变成排队

单行库存模型的瓶颈不是“这条 SQL 写错了”，而是写入热点过于集中。请求越多，等待这同一把行锁的事务越多，系统吞吐不再跟应用实例数量线性增长。

可以从三个信号判断是否进入热点行瓶颈：

• 锁等待时间上升：业务慢日志里相同 SKU 的扣减耗时变长。
• 连接池占用上升：请求没有大量计算，却长时间占着数据库连接。
• 库存 SQL 高度集中：慢查询或业务日志显示热点都落在少数 sku_id。

此时继续简单加应用机器，收益会变差。因为瓶颈已经不是入口请求处理，而是同一行更新只能串行通过。

新架构：把库存拆成多个可扣减分桶

分桶库存的核心思路，是把一个 SKU 的可用库存拆成多行。每次扣减时先选一个桶，只更新这一桶的库存。这样同一个 SKU 的并发请求可以落到不同库存行上，锁等待被摊开。

CREATE TABLE sku_stock_bucket (
  sku_id BIGINT NOT NULL,
  bucket_no INT NOT NULL,
  available INT NOT NULL,
  updated_at DATETIME NOT NULL,
  PRIMARY KEY (sku_id, bucket_no)
) ENGINE=InnoDB;

初始化时，把总库存拆到多个桶里：

INSERT INTO sku_stock_bucket(sku_id, bucket_no, available, updated_at)
VALUES
(10001, 0, 250, NOW()),
(10001, 1, 250, NOW()),
(10001, 2, 250, NOW()),
(10001, 3, 250, NOW());

扣减时选择一个桶，例如根据订单号、用户 ID 或随机数做分布：

UPDATE sku_stock_bucket
SET available = available - 1,
    updated_at = NOW()
WHERE sku_id = 10001
  AND bucket_no = 2
  AND available > 0;

如果选中的桶没有库存，可以按业务要求做一次有限重选，或者直接返回库存不足。这里不要无限循环重试，否则热点会从单行争用变成重试风暴。

关键取舍：锁压力下降，但一致性边界变多

分桶库存能降低行锁争用，但它不是免费优化。它把“一个库存数字”拆成了多个局部数字，系统需要额外处理汇总、校验和边界情况。

取舍一：总库存查询要汇总

以前查一行即可看到库存，现在要汇总多个桶：

SELECT SUM(available) AS total_available
FROM sku_stock_bucket
WHERE sku_id = 10001;

如果这个查询也很频繁，就不能每次都扫桶表。可以把展示库存放到缓存或汇总表里，扣减链路只保证核心库存行正确，展示值允许短暂延迟。

取舍二：分桶数不是越大越好

桶越多，单行争用越小，但汇总、初始化、补偿和监控也越复杂。小流量商品没有必要分太多桶。实践上可以按热点等级配置，例如普通 SKU 4 个桶，活动 SKU 16 个桶，极端热点再走专门链路。

取舍三：失败处理要有明确边界

某个桶扣减失败，不一定代表整个 SKU 没库存，可能只是这个桶空了。业务要决定是否允许重选桶。建议限制重选次数，并记录失败原因：桶空、库存总量不足、锁等待超时、数据库错误要区分开。

上线结果：看锁等待、失败率和库存差异

分桶库存上线后，不要只看“接口没有报错”。至少要观察三组指标。

上线验证可以先灰度一小部分热点 SKU。灰度期间保留旧链路开关，发现桶分布不均、失败率异常或汇总差异扩大时，能快速切回单行模型或暂停活动链路。

后续改进：分桶数、补偿和降级开关

分桶库存稳定后，还可以继续做三类改进。

第一，动态调整热点 SKU 的桶数

活动前根据历史峰值预估桶数，活动中根据锁等待和失败率判断是否需要扩桶。扩桶要配合库存重新分配，不能简单插几行空桶就结束。

第二，建立库存流水和对账任务

每次扣减最好写入库存流水，记录订单号、SKU、桶号、变化数量和业务状态。对账任务定时核对桶汇总、订单状态和流水，发现差异及时补偿。

第三，保留降级策略

如果数据库锁等待异常升高，可以按 SKU 关闭活动入口、降低下单并发、启用排队页，或切换到更保守的库存校验策略。库存链路宁可短暂限流，也不要让数据库连接池被热点更新拖满。

总结一下，MySQL 热点库存行的问题，本质是把高并发写入压到了同一行上。单行扣减简单可靠，但在大促热点里容易形成行锁队列；分桶库存能把写压力摊开，但要付出汇总、对账、重选桶和灰度开关的复杂度。判断是否采用它，应该看锁等待、热点 SKU 占比、库存一致性要求和团队维护能力，而不是看到高并发就直接上复杂架构。