库存扣减怎样优化表结构设计，真正难的通常不是把 stock 改成 stock - 1，而是回答三个问题：当前还剩多少、这次变化为什么发生、同一笔业务是否已经扣过。很多库存事故并非源于数据库不会做减法，而是表结构把“当前状态”“订单占用”“历史过程”混在了一起，最终导致超卖、重复扣减、取消订单无法释放，以及账面库存无法解释。

数据库存：技术负责人案例思路：库存扣减怎样优化表结构设计

一、先讲核心结论：库存表不是数字表，而是状态与事实的组合

1. 先把库存问题拆成三个问题

我在参与库存模型设计和改造时，通常不会先讨论要不要加索引、要不要使用缓存，而是先把库存拆成三个完全不同的问题。

• 状态问题：现在某个 SKU、某个仓库、某个批次还剩多少可销售库存。
• 事实问题：库存曾经发生过哪些预占、扣减、释放、回补和人工调整。
• 一致性问题：某笔订单、某个请求或某条消息是否已经处理过，失败后能否安全重试。

这三个问题如果都依赖一张库存表中的一个数量字段来解决，系统在业务简单时可能看不出问题，一旦出现支付超时、订单取消、重复回调或人工调账，开发人员就会发现：数据库只告诉你“现在是 37 件”，却无法说明这 37 件是怎么来的。

因此，我更倾向于把库存设计成三类数据的组合：库存汇总表负责当前状态，库存流水表负责变化事实，库存预占表负责订单生命周期中的占用关系。这不是“表越多越专业”，而是让每张表只承担一种主要职责。

2. 推荐的核心模型

单表方案并不是绝对错误。低并发、无预占、无复杂售后、无需追溯的内部业务，使用一张汇总表就可能足够。真正需要避免的是：业务已经出现预占和回滚，数据库模型却仍然停留在“库存数量减一”的阶段。

3. 先定义库存口径，再定义字段

库存设计最容易被忽视的一步，是先明确字段代表什么。很多系统同时存在“库存”“可售库存”“锁定库存”“实际库存”“剩余库存”等名称，但没有统一计算关系，最后不同服务各自理解，报表和接口返回值自然会出现差异。

一个常见且相对清晰的口径是：

可用库存 = 总库存 – 预占库存 – 冻结库存 – 其他不可销售库存

但这个公式只是一种业务口径，不是数据库定律。例如仓储系统可能还需要区分在库、质检、残次、调拨中和在途；电商系统可能只关心可售库存和预占库存；按批次管理的商品还需要考虑效期、批次和先进先出。

不要因为字段看起来完整，就认为库存模型完整。如果产品、仓库、订单和财务团队对“可用库存”的定义不同，增加再多字段也只是把口径冲突保存得更复杂。

二、背景和真实场景：库存事故往往发生在正常流程之外

1. 一个看起来很简单的扣减流程

假设某 SKU 当前库存为 1 件。两个用户几乎同时提交订单，应用程序先执行查询：

SELECT available_qty
FROM stock_summary

WHERE sku_id = 10001;

两个请求都读到 1，随后各自执行扣减。如果扣减语句没有再次把“库存足够”作为数据库条件，两个请求都可能成功，最终库存变成 -1，或者因为代码覆盖写导致数据库仍显示 0，但实际已经卖出了 2 件。

问题不在于查询语句本身，而在于系统把“判断库存是否足够”和“扣减库存”拆成了两个可以被并发打断的动作。应用层看到的库存只是某个时间点的快照，并不代表更新时仍然成立。

2. 真实业务里还有四类反常场景

第一类是重复请求。用户点击两次提交、移动网络重试、网关超时重放，都可能让同一个订单项到达库存服务两次。如果没有幂等控制，库存扣减会被执行两遍。

第二类是支付和下单不同步。订单创建成功后，用户可能长时间不支付。系统如果下单即扣除可售库存，就需要一个预占关系和超时释放机制，否则库存会被大量“僵尸订单”占住。

第三类是回滚与再次销售交叉。某订单取消时，库存已经被另一笔订单占用。此时“把库存加回去”并不是简单动作，必须确认原来的扣减是否成功、是否已经释放过，以及当前数量是否允许回补。

第四类是人工调整。仓库盘点发现少货、破损或批次过期时，工作人员需要修正库存。如果只是直接修改数字，事后没人能判断这次变化是系统订单造成的，还是人工操作造成的。

3. 我最先检查的不是表，而是库存事件清单

面对一个已经出现库存差异的系统，我一般先拿出最近一周的库存异常样本，按事件分类，而不是立即重写建表语句。通常会列出下单预占、支付确认、订单取消、支付超时、售后退货、仓库盘亏、手工调账和定时任务补偿等事件。

如果团队无法对每种事件回答“哪个字段增加、哪个字段减少、是否写流水、幂等键是什么、失败如何重试”，说明问题首先是业务状态不完整，而不是索引还不够多。

这种排查方式有一个实际好处：它能防止技术负责人把资源投入到错误方向。例如，查询耗时只有 5 毫秒，但取消订单没有可靠释放路径，此时继续做读写分离并不能解决核心问题。

三、常见误区：看似简单的表结构为什么会失控

1. 误区一：只保存一个 stock 字段

最初的库存表可能只有商品编号、仓库编号和库存数量。这个设计在展示页面上很直观，但它把所有库存变化都压缩成一个结果，无法区分预占、已售、冻结、盘亏和回补。

如果订单创建时扣减一次，支付成功后又扣减一次，团队就会遇到重复扣减；如果订单创建时只是扣减库存，取消订单再加回库存，团队又无法确认这次加回对应哪一次扣减。

单字段模型最大的风险，不是字段少，而是缺少业务事件的身份。没有业务单号、事件类型和幂等键，任何补偿任务都只能靠猜。

2. 误区二：先 SELECT，再在代码里判断，再 UPDATE

下面这种代码在单线程测试中通常表现正常，但在并发环境下存在典型竞态：

SELECT available_qty FROM stock_summary WHERE sku_id = ?;
if (available_qty >= request_qty) {

UPDATE stock_summary

SET available_qty = available_qty - ?

WHERE sku_id = ?;

}

两个请求可以在同一时间完成查询，然后同时通过应用层判断。即使数据库使用了事务，如果查询没有加锁，或者事务隔离和锁范围没有被正确理解，也不能自动保证这段逻辑安全。

更稳妥的基础写法是让数据库直接判断条件并完成更新：

UPDATE stock_summary
SET available_qty = available_qty - :qty,

sold_qty = sold_qty + :qty,

updated_at = CURRENT_TIMESTAMP

WHERE sku_id = :sku_id

AND warehouse_id = :warehouse_id

AND available_qty >= :qty;

应用层读取受影响行数：返回 1 表示本次条件更新成功，返回 0 则需要进一步区分库存不足、记录不存在或库存状态不允许扣减。这里的“原子更新”解决了超卖的一个关键环节，但还没有解决幂等、流水和跨服务一致性。

3. 误区三：把 reserved_qty 当成万能字段

增加 reserved_qty 是进步，但如果没有定义它由哪些业务动作产生，字段仍然会逐渐失真。下单预占、风控冻结、仓库锁定和营销活动预留，可能都被写进同一个字段，但它们的释放条件并不相同。

订单预占通常随订单状态变化而释放；风控冻结可能由人工审核解除；营销预留可能由活动结束统一回收。它们应该至少在流水类型或预占类型上可区分，必要时还应拆成不同的业务关系。

字段数量不是状态建模，状态变化规则才是状态建模。如果一个字段的值需要依赖多个服务各自解释，最终一定会出现“数字一致但含义不一致”的情况。

4. 误区四：库存流水只记录 change_qty

只记录变更数量，例如“扣减 3 件”，并不能在数据异常时准确还原上下文。更有用的流水至少应保存变更前数量、变更数量和变更后数量。

其中，变更前和变更后数量并不是为了让报表更好看，而是为了帮助排查并发和补偿问题。例如同一个业务单号出现两条流水时，可以判断它们是否基于同一个库存状态产生；如果前后数量无法衔接，则说明存在并发写入、重复补偿或人工改数。

流水表中的数量是“当时的事实快照”，不能简单理解为通过流水实时累加得到的唯一真相。生产系统仍需定期通过汇总表和流水表做对账，发现差异后进入补偿或人工审核流程。

5. 误区五：用 Redis 替代数据库模型

缓存可以帮助热点库存削峰、快速判断或串行处理，但它不是库存事实本身。只在缓存中扣减而不定义落库、消息失败、服务重启和对账机制，系统只是把数据库问题换成了缓存与数据库之间的一致性问题。

我更愿意把缓存视为一种性能组件，而不是业务账本。最终需要明确：缓存扣减成功后如何形成持久化事实，数据库更新失败如何补偿，消息重复消费如何幂等，缓存和数据库不一致时以谁为准。

6. 误区六：一开始就分库分表

库存表确实可能成为热点表，但分库分表不是解决所有库存问题的第一步。如果团队还没有统一库存口径、幂等规则和对账流程，分库分表只会让问题更难排查。

许多系统的首要瓶颈其实是热点行锁等待、事务中执行了复杂查询，或者流水表索引过多导致写入变慢。应先通过慢查询、锁等待、事务耗时和热点 SKU 分布确认瓶颈，再决定是否做分片、队列化或库存分桶。

四、专业判断逻辑：如何从业务约束推导表结构

1. 第一步：确定库存的最小隔离维度

库存记录不能只按商品编号设计。对于同一个 SKU，如果北京仓和上海仓不能互相调拨，那么库存维度至少是“SKU + 仓库”；如果同一仓库内不同批次效期不同，则还需要加入批次；如果不同渠道有独立配额，则可能是“SKU + 仓库 + 渠道”。

我会先问业务方一个反向问题：哪些库存可以互相替代？能够互相替代的库存才适合进入同一个可用池，不能替代的库存必须在数据模型中隔离。

例如，普通商品可能按照仓库汇总；冷链食品需要按批次和效期管理；票务座位则需要按场次、区域、座位号管理。三者都叫库存，但唯一键和扣减粒度完全不同。

2. 第二步：区分“库存事实”和“库存视图”

库存汇总表本质上是一个面向高频读写的当前状态视图。它应该尽量让下单路径快速判断和更新，而不应该承担所有历史、报表和审计查询。

库存流水表则保存每次库存事件。它是事实记录，通常只追加，不建议频繁修改历史流水。即使发现之前记录错误，也应新增一条更正或冲正流水，而不是直接覆盖原记录。

这种设计类似财务系统中的余额与账务明细：余额用于快速查询，明细用于解释余额。两者需要定期核对，但职责不能混为一谈。

3. 第三步：判断是否需要库存预占

下单到支付之间存在时间差时，通常需要预占。预占不是“已经卖出”，它表示这部分可售库存暂时不能被其他订单使用。

如果业务是立即支付、没有长时间待支付状态，直接扣减可能更简单。但如果支付渠道有较长确认时间、订单需要风控审核，或者用户可以在购物车中保留库存，就应该单独记录预占关系。

预占表的价值在于：它能把库存占用和订单项建立明确关系。定时任务可以按照 expire_at 查询到期预占并释放，售后或取消流程也可以判断这笔库存是否已经被确认或释放。

4. 第四步：把幂等设计成数据库约束

幂等不能只依赖应用层的“先判断一下”。两个并发请求可能同时判断“尚未处理”，然后一起扣减。更稳妥的做法，是为业务事件设计稳定的幂等键，并在库存流水或扣减记录中建立唯一约束。

幂等键可以是订单项编号、订单号加 SKU、支付确认事件号，或者库存操作请求号。选择标准不是字段看起来是否唯一，而是同一个业务事件重试时，是否一定能生成同一个键。

建议在设计评审时逐项确认：

• 用户重复点击是否生成同一个业务单号。
• 网关重试是否保留原始请求号。
• 消息重复消费是否携带同一个事件 ID。
• 取消与支付确认是否可能乱序到达。
• 释放预占和回补已售库存是否使用不同事件类型。

5. 第五步：控制事务边界，而不是把所有动作放进一个大事务

在同一个数据库中，库存汇总更新、库存流水写入和预占记录写入可以放在一个短事务内。这样可以保证：汇总状态已经变化时，流水记录不会缺失；流水写入成功时，汇总数量不会停留在旧值。

但订单库、库存库、支付系统和消息系统往往不在同一个事务中。此时不能简单地说“加事务就一致”，而应设计本地消息表、Outbox、事务消息或补偿任务，并明确每个状态的最终收敛方式。

一个实用原则是：数据库事务负责本地原子性，消息机制负责跨系统传播，补偿和对账负责最终收敛。不要让一个超大分布式事务把库存主链路锁住。

五、表结构设计：从一张汇总表演进到可追溯模型

1. 库存汇总表应该保存什么

汇总表只保存扣减主链路需要快速读取和更新的状态。一个通用示例如下：

CREATE TABLE stock_summary (
id BIGINT NOT NULL PRIMARY KEY,
sku_id BIGINT NOT NULL,
warehouse_id BIGINT NOT NULL,
total_qty INT NOT NULL DEFAULT 0,
available_qty INT NOT NULL DEFAULT 0,
reserved_qty INT NOT NULL DEFAULT 0,
sold_qty INT NOT NULL DEFAULT 0,
frozen_qty INT NOT NULL DEFAULT 0,
version INT NOT NULL DEFAULT 0,
updated_at TIMESTAMP NOT NULL,
UNIQUE KEY uk_sku_warehouse (sku_id, warehouse_id)
);

这个表的关键不是字段越多越好，而是每个字段都必须有明确的变化规则。比如支付确认时，如果库存已经在下单阶段从可用转为预占，那么支付确认不应再次减少 available_qty，而应将 reserved_qty 减少、sold_qty 增加。

字段名称也要避免歧义。total_qty 是实物总量、系统账面总量，还是可销售总量？如果无法统一，宁可拆成更明确的字段，也不要让同一个字段被不同服务按不同含义使用。

2. 库存流水表应该记录什么

库存流水表建议采用追加式设计。示例如下：

CREATE TABLE stock_flow (
id BIGINT NOT NULL PRIMARY KEY,
flow_no VARCHAR(64) NOT NULL,
biz_no VARCHAR(64) NOT NULL,
event_id VARCHAR(128) NOT NULL,
sku_id BIGINT NOT NULL,
warehouse_id BIGINT NOT NULL,
change_type VARCHAR(32) NOT NULL,
before_available_qty INT NOT NULL,
change_available_qty INT NOT NULL,
after_available_qty INT NOT NULL,
before_reserved_qty INT NOT NULL,
change_reserved_qty INT NOT NULL,
after_reserved_qty INT NOT NULL,
operator_type VARCHAR(32) NOT NULL,
source_system VARCHAR(64) NOT NULL,
created_at TIMESTAMP NOT NULL,
UNIQUE KEY uk_event_id (event_id),
KEY idx_biz_no (biz_no),
KEY idx_sku_warehouse_time (sku_id, warehouse_id, created_at)
);

event_id用于幂等，biz_no用于追踪订单或调账单，change_type用于区分事件来源。对于人工调整，还应记录操作人、审核单号和调整原因；对于系统任务，则应记录任务批次和补偿来源。

流水表字段可能比汇总表更多，但不要把所有业务对象都直接复制进来。订单名称、商品标题等易变信息通常不适合成为库存流水事实的一部分，流水应优先记录能够支持库存核对的稳定标识。

3. 预占表应该表达订单生命周期

存在待支付、待审核或锁座流程时，可以设计预占表：

CREATE TABLE stock_reservation (
id BIGINT NOT NULL PRIMARY KEY,
reservation_no VARCHAR(64) NOT NULL,
order_no VARCHAR(64) NOT NULL,
order_item_no VARCHAR(64) NOT NULL,
sku_id BIGINT NOT NULL,
warehouse_id BIGINT NOT NULL,
reserved_qty INT NOT NULL,
status VARCHAR(24) NOT NULL,
expire_at TIMESTAMP NOT NULL,
confirmed_at TIMESTAMP NULL,
released_at TIMESTAMP NULL,
created_at TIMESTAMP NOT NULL,
updated_at TIMESTAMP NOT NULL,
UNIQUE KEY uk_order_item (order_item_no),
KEY idx_expire_status (status, expire_at),
KEY idx_sku_warehouse_status (sku_id, warehouse_id, status)
);

这里的唯一键尤其重要。同一个订单项如果重复收到预占请求，不应产生两条有效预占。状态字段也不能只用一个布尔值，至少要能区分有效预占、已确认、已释放和已过期。

4. 三张表的事务写入顺序

以“下单预占”为例，一个短事务可以按照以下顺序执行：

1. 根据订单项或事件号检查幂等记录。
2. 对库存汇总表执行带条件的可用库存扣减。
3. 插入库存预占记录。
4. 插入库存流水记录。
5. 提交事务并返回预占结果。

库存汇总表中的变化可以是 available_qty - qty 和 reserved_qty + qty。支付确认时，不应再从可用库存扣减，而是完成预占到已售的状态迁移。订单取消或超时时，则执行相反方向的释放动作。

如果第 2 步成功但第 3 步失败，事务应整体回滚。若跨数据库或跨服务，不能依赖这套本地事务，需要通过事件状态和补偿任务保证最终一致。

六、并发扣减：原子更新只是起点

1. 使用条件更新避免典型超卖

对于普通 SKU 和单行库存，优先考虑数据库条件更新。核心语句如下：

UPDATE stock_summary
SET available_qty = available_qty - :qty,

reserved_qty = reserved_qty + :qty,

version = version + 1,

updated_at = CURRENT_TIMESTAMP

WHERE sku_id = :sku_id

AND warehouse_id = :warehouse_id

AND available_qty >= :qty;

这条语句把“库存足够”和“扣减动作”放在同一个数据库更新中。多个请求竞争同一行时，数据库会按照自身的锁机制完成更新，后续请求会基于最新值判断，而不是继续使用旧的查询结果。

但返回 0 行并不等于只有库存不足一种情况。生产代码需要区分库存记录缺失、维度不匹配、商品已下架、可用库存不足和数据库异常，否则前端可能把所有错误都显示成“库存不足”，排查成本会很高。

2. 版本号乐观锁适合冲突可控的场景

另一种方式是增加版本号：

UPDATE stock_summary
SET available_qty = available_qty - :qty,

reserved_qty = reserved_qty + :qty,

version = version + 1,

updated_at = CURRENT_TIMESTAMP

WHERE sku_id = :sku_id

AND warehouse_id = :warehouse_id

AND available_qty >= :qty

AND version = :version;

乐观锁可以检测读取之后是否有其他请求修改过记录。如果更新失败，应用层可以重新读取并重试。不过，热点 SKU 的冲突率很高时，重试会放大数据库压力，甚至出现大量请求重复争抢同一行。

因此，我不会把“乐观锁”简单等同于高并发方案。它适合冲突概率可控、重试次数可限制、业务允许短暂失败的场景；对强热点 SKU，则需要进一步考虑排队、分片、库存分桶或预分配。

3. 悲观锁不是越重越安全

使用 SELECT ... FOR UPDATE可以在事务内锁住库存行，但事务必须足够短。若持锁期间还调用支付接口、远程订单服务或执行复杂查询，行锁等待会迅速扩大。

正确的使用方式通常是：进入事务，锁定单行库存，完成数量判断和更新，写入本地流水，立即提交。远程调用不应放在持锁事务中，外部结果应通过状态机和补偿机制处理。

4. 多个库存维度需要避免锁顺序不一致

一个订单包含多个 SKU 时，事务可能同时更新多行库存。如果请求 A 按 SKU 1、SKU 2 的顺序加锁，请求 B 按 SKU 2、SKU 1 的顺序加锁，就有死锁风险。

常见处理方式是对订单项按稳定顺序排序，例如按照库存记录主键或 SKU 编号升序更新。无论哪个请求进入，都遵循同一锁顺序，可以显著降低死锁概率。

此外，还应设置合理的死锁重试和事务超时。死锁重试不是无限重试，通常需要限制次数，并在超过阈值后记录完整上下文，交给监控和补偿流程处理。

七、案例拆解：从“只改库存数字”到可对账库存模型

1. 案例背景与问题表现

下面是一组脱敏后的情景案例，数据用于说明改造思路，不对应某一家企业。业务是多仓电商，订单创建后先锁定库存，支付成功后确认销售，未支付订单在 30 分钟后自动释放。

原系统只有一张库存表，每次下单直接减少 stock_qty，支付成功不再变更库存，取消订单则把数量加回。运行一段时间后出现三个问题：客服无法解释库存差异，重复取消会导致库存虚增，定时释放任务失败后没有可靠的补偿依据。

团队最初的判断是数据库更新慢，但观察监控后发现，库存扣减 SQL 的平均执行时间只有 6 毫秒，P99 约为 38 毫秒；真正难排查的是业务事件没有唯一身份，系统也没有记录“这次加回对应哪次扣减”。

2. 改造前后的数据观察

改造前，库存表只有当前数量，排查一次异常平均需要人工比对订单、支付和仓库表，通常要花费半天。改造后，系统为每次库存变化生成事件号，汇总表和流水表在同一数据库事务中写入，订单项与预占记录建立唯一关系。

在连续 14 天的情景观察中，重复库存请求占库存相关请求的约 2.7%，支付超时和取消释放约占有效预占事件的 11.4%。这两个比例说明：如果只测试“正常下单并支付”，很难暴露库存模型的真实缺陷。

这里的重点不是“改造后一定能达到某个固定耗时”，而是排查路径发生了变化。库存系统的可靠性不只体现在扣减接口成功率，还体现在出现异常时能否迅速回答：哪个业务事件造成了变化，是否重复执行，当前状态是否已经收敛。

3. 改造后的关键写入逻辑

预占库存时，系统先用订单项生成稳定的事件号。例如事件号可以由业务动作和订单项组成：

reservation:create:{order_item_no}

之后在一个本地事务中完成幂等检查、条件更新、预占记录和流水写入。为了避免重复插入造成事务异常，流水表的唯一键应覆盖事件号；应用层捕获唯一键冲突后，需要再次读取原处理结果，而不是简单返回“系统错误”。

支付确认时，系统检查订单项是否存在有效预占。如果预占已经释放，支付确认不能直接把库存标记为已售；它应进入异常处理或人工审核状态。否则，支付事件和释放事件乱序到达时，就可能出现库存已经回收但订单却继续确认的矛盾。

这也是我在评审库存方案时非常关注的一点：每个动作不仅要有成功路径，还要有乱序、重复和部分失败路径。如果设计文档只画了“下单，支付，发货”的直线流程，通常还不足以支撑生产系统。

4. 改造没有解决什么问题

三表模型并没有消除热点 SKU 的行锁竞争，也没有自动解决跨库消息丢失。它解决的是状态职责、事件追溯和订单占用关系。

如果某个热门 SKU 在高峰期间每秒有数千次请求，数据库单行仍然可能成为瓶颈。这时需要结合业务选择分桶库存、队列串行、预分配库存或缓存削峰，而不是认为拆成三张表后并发问题自然消失。

同样，流水表会持续增长，需要规划按月分区、冷热数据分离和历史归档。如果只增加流水不做生命周期管理，几个月后查询和索引维护可能成为新的性能问题。

八、索引、字段和数据生命周期：优化不止是加一个唯一键

1. 唯一键必须对应库存隔离规则

如果库存按照 SKU 和仓库隔离，那么汇总表至少应建立：

UNIQUE KEY uk_sku_warehouse (sku_id, warehouse_id)

如果还存在批次和渠道隔离，就必须把它们纳入唯一性定义。不能先按 SKU 建唯一键，后来再通过代码判断仓库，否则不同仓库可能错误地共享同一行库存。

唯一键不仅防止重复记录，还决定了条件更新命中的粒度。库存维度设计错误时，后续无论使用行锁还是乐观锁，锁住的都可能是错误的业务对象。

2. 索引要服务于具体 SQL

库存汇总表的索引通常围绕精确匹配设计，因为扣减语句一般按 SKU、仓库、批次等维度命中单行。不要给每个数量字段都建立索引，数量字段经常变化，额外索引会增加更新成本。

预占表则需要支持两类查询：按订单项查询一条预占关系，以及按状态和过期时间扫描待释放记录。对应的索引可以分别覆盖订单项唯一键和 status + expire_at。

流水表常见查询包括按业务单号追溯、按 SKU 和仓库按时间回放、按事件类型统计。因此索引需要围绕真实查询建立，而不是把订单号、SKU、仓库、时间、类型全部分别单列索引。

3. 流水表增长到什么程度需要治理

如果每天有 50 万笔库存事件，每笔流水平均占用 500 字节，仅数据正文一个月就约 7.5 GB，还没有计算索引、页填充、备份和副本开销。实际占用通常会更高。

因此，在设计流水表时就应回答：

• 实时排查需要保留多长时间。
• 历史流水是否需要在线查询。
• 是否按照月份或仓库进行分区。
• 归档后能否通过离线系统检索。
• 对账任务是否会扫描全表。
• 索引是否会影响高峰期写入。

我通常建议实时流水表只服务近期开单、售后和异常排查，历史数据转入归档表或分析库。库存主链路不应被报表查询拖慢，也不应让无限增长的流水索引持续影响写入。

4. 数量字段和时间字段也有边界

库存数量使用什么类型，取决于业务上限和是否允许小数。件数库存通常使用整数，但重量、长度或体积库存可能需要定点小数。不要为了省空间把可能超过整数上限的库存数量设得过小，也不要用浮点数保存需要精确对账的数量。

时间字段应统一时区策略。预占过期任务、仓库批次和跨地区订单都可能受到时区影响。数据库保存 UTC 时间，应用展示时转换，通常比各服务使用本地时间更容易统一。

九、不同业务情况下的行动建议

1. 低并发、无预占的内部业务

如果系统每天只有几千次库存变化，库存主要用于内部领用或简单商品管理，且不存在支付等待和复杂售后，可以从库存汇总表加库存流水表开始，不必一开始就引入复杂的预占状态机。

最低配置建议包括：

• SKU 与库存维度的唯一键。
• 带库存条件的原子更新。
• 业务单号和事件号。
• 人工调账的原因和操作人。
• 至少一种定期对账方式。

这种场景的重点是保持简单，但不能牺牲可解释性。单表可以简单，不能没有幂等和流水。

2. 中等并发、存在待支付订单的电商业务

这类业务建议采用库存汇总表、库存流水表和库存预占表。下单时预占，支付确认时完成状态迁移，取消或超时后释放。

行动顺序可以是：

1. 先确定订单项级别的唯一幂等键。
2. 定义预占有效期和释放规则。
3. 为状态迁移设计合法路径和非法路径。
4. 使用条件更新保护可用库存。
5. 增加到期扫描、重试和人工补偿。
6. 通过流水与订单表做日常对账。

不要把“支付成功”简单理解为再次扣库存。若下单阶段已经减少可用库存，支付确认通常只是把预占转成已售。

3. 热点 SKU 和秒杀类业务

热点 SKU 的核心矛盾是大量请求竞争同一库存记录。此时即使 SQL 只有几毫秒，单行锁也可能在高峰期排队。

可以根据业务是否允许延迟选择不同策略：

• 允许短暂排队：按 SKU 将请求进入队列，单线程或有限并发消费。
• 需要更高吞吐：将库存拆成多个库存桶，降低单行竞争，但需要防止桶之间的分配不均。
• 可接受异步确认：先做资格校验，再异步创建订单，明确用户看到的是“排队中”而不是“已购买”。
• 采用缓存预扣：必须同时建设落库、补偿、恢复和对账体系。

我不建议把秒杀系统的设计直接套到普通电商库存。秒杀可以接受排队、失败重试和异步结果，普通订单可能要求即时确认；两者的用户体验和一致性约束不同。

4. 多仓、多渠道和批次库存

多仓库存不能只在查询时根据仓库筛选，表结构的唯一键和扣减条件必须从一开始就包含仓库维度。多渠道库存则要明确共享池和独占池，避免一个渠道的预占影响另一个渠道的销售承诺。

批次库存还要考虑效期和出库策略。此时“扣减某个 SKU 的 10 件”是不完整的，系统需要先选择满足规则的批次，再对具体批次库存执行扣减。批次选择和库存扣减之间要避免被其他订单抢占，必要时需要在事务内锁定候选批次。

5. 需要高频分析和经营报表的业务

经营分析、库存周转、缺货率和补货预测不应直接对实时库存流水表做复杂聚合。实时数据库适合支撑订单和库存主链路，分析库或数据集市更适合处理长周期统计。

如果团队使用某数据分析平台进行库存看板，可以将库存汇总、流水、订单和采购数据按统一主键同步到分析层。这样既能保留实时系统的短事务，又能让经营人员分析库存变化原因、仓库差异和滞销结构。

这里不需要把分析工具写入库存核心事务。分析系统的职责是解释和观察，不应成为库存扣减成功与否的依赖。

十、方案取舍：什么时候单表足够，什么时候必须拆表

1. 单表方案的优势和边界

单表的优势是开发快、查询简单、事务路径短，特别适合库存维度少、业务状态简单的系统。它也便于早期验证业务流程，不会因为过度建模拖慢上线。

它的边界也很清楚：没有足够的流水和业务关联时，审计、回滚和异常修复会变得困难。如果系统已经需要支付超时释放、订单项级预占和人工调账，单表方案往往只是把复杂度隐藏到了代码和人工操作中。

2. 两表方案的优势和边界

汇总表加流水表是比较稳妥的中间形态。汇总表保障高频读写，流水表保留库存变化事实，适合多数普通商品和内部库存系统。

它的限制是：如果订单占用关系只放在订单系统里，库存服务仍可能无法快速判断某一笔预占是否已释放。对于支付等待时间较长的业务，建议增加预占表，或者至少建立等价的库存占用记录。

3. 三表方案的优势和边界

三表方案能够把当前状态、变化事实和订单占用关系分离，适合多状态库存、复杂取消、预占过期和售后回补场景。它也更利于构建定时释放、异常补偿和按订单项核对的能力。

但三表会增加事务编排、状态迁移、归档和监控成本。团队需要维护状态机，处理跨库传播，还要确保汇总表、流水表和预占表能够定期对账。如果业务不需要这些能力，三表可能是过度设计。

十一、上线前的验证方法：不要只做正常下单测试

1. 用事件矩阵覆盖库存状态

测试用例应该以库存事件为中心，而不是只写“下单成功”。至少覆盖下单预占、重复预占、支付确认、重复支付回调、取消、超时释放、释放重试、售后回补、人工调整和库存不足。

每个事件都应明确测试前置状态、预期汇总数量、预期流水数量、预占状态和重复执行结果。这样才能发现“接口返回成功，但流水没有写入”或“重复调用返回成功，却再次改变数量”的问题。

2. 做并发测试和锁等待观察

并发测试不应只看接口平均响应时间。至少应同时观察：

• 库存是否出现负数。
• 成功订单数量是否超过初始可用库存。
• 重复请求是否只产生一次有效变更。
• 数据库锁等待和死锁次数。
• 事务平均耗时与 P99 耗时。
• 流水表是否存在数量断层。

如果 1000 个请求同时争抢 100 件库存，最终有效扣减应该严格不超过 100 件。接口失败并不等于系统异常，关键是失败请求不能改变库存，成功请求必须能够找到对应业务事实。

3. 做乱序和故障注入

支付确认先到、预占消息后到，或者取消消息重复到达，这些情况在分布式系统中并不罕见。可以在测试环境中人为延迟消息、重复投递、重启消费者和模拟数据库超时，验证状态机是否能拒绝非法迁移并进入补偿队列。

库存服务的可靠性不是“所有请求都成功”，而是失败发生后系统仍然可恢复。一个成熟的设计应能明确告诉运维人员：哪些事件已处理，哪些事件待重试，哪些事件需要人工审核。

4. 建立汇总表与流水表的对账规则

对账不一定要每次请求都扫描完整流水，但必须有周期性机制。可以按 SKU、仓库和日期汇总流水变化，与汇总表的当前数量进行核对；对于存在初始盘点、采购入库和报损的系统，还要把这些业务来源纳入统一口径。

发现差异后，不建议直接修改库存汇总表。正确做法通常是先生成差异单，核对订单、预占、流水和仓库实物，再通过一条有审核记录的调整流水修正，并保留调整前后的数量。

十二、下一步怎么做：从最小改造开始，而不是一次重写所有库存

1. 第一周先做库存事件盘点

列出系统所有会改变库存的接口、任务和消息消费者，给每个动作标注变更字段、业务单号、幂等键、事务边界和失败处理方式。这个过程通常比直接改表更能暴露问题。

如果某个动作无法说明“为什么改变库存”，先暂停新增字段，优先补齐业务定义。否则，新表只会把旧问题重新分散到更多字段中。

2. 第二步补齐原子更新和幂等约束

在不改变整体业务流程的前提下，先把无条件减法替换为带条件更新，并为重复请求建立稳定的唯一事件号。这样可以先解决最危险的超卖和重复扣减问题。

上线前应准备历史数据兼容策略。旧订单可能没有事件号，不能简单地把空值写入唯一键；可以根据订单项、操作类型和时间窗口生成迁移标识，并对冲突数据进行人工确认。

3. 第三步引入流水，再处理复杂预占

如果当前系统还没有库存流水，建议先让每次库存变更形成可追溯记录，再引入预占状态。这样团队可以用流水观察新模型是否与旧流程一致，也能在改造期间及时发现数量差异。

预占表不要只为了“看起来完整”而增加。应在确实存在待支付、锁定、审核或超时释放时引入，并配套状态迁移、到期扫描、补偿和监控。

4. 最后根据压力决定是否引入缓存或队列

只有在监控确认热点行锁、数据库连接或高峰请求已经成为瓶颈时，才进入缓存预扣、队列串行或库存分桶阶段。每一种增强方案都要同时写出失败恢复和对账设计，不能只评估峰值吞吐。

我建议技术负责人在方案评审时要求提交三张图：库存状态流转图、事务边界图和异常补偿图。没有这三张图，单看建表 SQL 很难判断方案能否覆盖生产场景。

5. 上线前使用这份检查清单

• 库存最小隔离维度是否明确。
• 可用、预占、已售、冻结和在途是否有清晰定义。
• 汇总表是否使用正确的唯一键。
• 扣减是否通过带条件的原子更新完成。
• 重复请求是否有稳定幂等键和数据库约束。
• 每次有效变化是否写入流水。
• 流水是否记录变更前、变更量和变更后数量。
• 支付确认是否会重复扣减可用库存。
• 取消、超时、售后和人工调账是否有独立事件类型。
• 多行库存更新是否遵循统一加锁顺序。
• 流水表是否规划分区、归档和查询边界。
• 跨库消息是否有重试、补偿和对账机制。
• 是否压测了热点 SKU，而不只是普通 SKU。
• 是否监控锁等待、P99、死锁、重复事件和对账差异。

十三、FAQ：库存表结构设计中最容易被忽略的问题

1. 库存汇总表和流水表的数据不一致，以哪张表为准？

实时下单路径通常以库存汇总表作为当前状态判断依据，流水表作为变化事实和审计依据。两者不应简单地互相覆盖，而应通过事务写入和定期对账保持一致。

如果发现不一致，不能直接认定某一张表永远正确。需要检查是否存在初始化库存、人工调账、历史迁移、流水丢失或重复补偿，再通过审核后的调整事件修正。

2. 预占库存应该在下单时扣，还是支付时扣？

如果下单后需要保证库存不会被其他订单使用，通常在下单时预占；支付成功后完成预占到已售的状态迁移。如果业务允许超卖后再确认，才可能在支付时直接扣减，但这需要接受支付成功后缺货的处理成本。

关键不在于哪个时点更“标准”，而在于用户承诺和库存口径是否一致。页面显示“已为你保留”时，数据库必须确实有对应的预占关系和过期释放机制。

3. 失败的库存扣减需要写流水吗？

没有改变库存数量的失败请求，一般不应作为库存变更流水写入，但可以写入操作日志或失败事件日志。真正改变库存后事务回滚的动作，也不应留下看似成功的库存流水。

如果团队需要分析库存不足请求，可以单独记录库存校验失败事件，区分“业务未扣减”和“库存已变更”。这能避免报表把失败尝试误算成库存变化。

4. 流水表是否需要保存变更后数量？

建议保存。变更前、变更量和变更后数量可以帮助排查并发、补偿和人工调账问题，尤其适合还原某个 SKU 在某段时间内的状态变化。

但保存前后数量不代表流水表天然就是唯一账本。仍然需要确保事件顺序、事务一致性和对账逻辑成立，否则前后数量本身也可能是错误数据。

5. 库存数量变成负数时，应该直接修正为零吗？

不建议直接修正。负数是一个结果，不是原因。直接改为零会破坏现场，使团队失去判断超卖、重复扣减、初始化错误或回补重复的机会。

更合理的方式是冻结相关 SKU 的自动调账，保留异常快照，检查订单、流水和消息处理记录，再通过有原因、有审核人的调整事件修正。

6. 为什么不建议把远程调用放在库存事务里？

远程调用耗时不可控，网络超时或服务抖动会延长数据库锁持有时间。热点库存行被长时间锁住后，后续请求会排队，最终表现为库存接口大面积超时。

本地事务只负责本地数据原子性，跨服务动作通过消息、状态机和补偿完成。即使业务最终一致，也比把远程调用塞进长事务更容易观察和恢复。

十四、总结：库存优化的终点不是三张表，而是每个数字都能被解释

库存扣减表结构设计的核心，不是寻找一份可以复制到所有系统的建表 SQL，而是根据业务状态和一致性要求，决定哪些数据需要实时更新、哪些事实必须追加保存、哪些订单关系需要单独维护。

如果业务简单，单汇总表可以是合理起点；如果需要审计和对账，增加流水表；如果存在待支付、超时释放和复杂订单生命周期，再引入预占表；如果热点 SKU 造成单行竞争，最后才考虑队列、分桶或缓存增强。

我对库存系统最重要的判断是：真正需要优化的往往不是“库存字段”，而是库存变化的解释能力。一个库存数字在正常流程中可能足够快，但在异常发生后，只有状态、事件、业务单号和补偿路径能够让它变得可信。

下一步可以先选择一个库存量大、异常频繁的 SKU，回放最近一周的下单、支付、取消、释放和调账记录，检查是否能逐笔解释汇总数量变化。解释不了的地方，就是表结构和业务流程最值得优先改造的地方。

UPDATE 中完成： UPDATE stock_summary SET available_qty = available_qty - :qty, sold_qty = sold_qty + :qty, updated_at = CURRENT_TIMESTAMP WHERE sku_id = :sku_id AND warehouse_id = :warehouse_id AND available_qty >= :qty;

免费注册

咨询方案

扫码咨询方案