数据库存：架构师实操版教程：库存流水从准备到复盘

库存系统最难排查的故障，往往不是“库存减错了 1 件”，而是系统在三天后仍然说不清这 1 件是从哪里来的。订单系统显示可售库存 8 件，仓库盘点为 6 件，销售平台却展示 10 件；如果数据库里只有一张库存余额表，开发人员通常只能手工改数字，却无法回答哪笔订单、哪次重试、哪次人工调整造成了差异。我的判断是：库存余额负责快速回答“现在有多少”，库存流水负责解释“为什么是这个数”。

这篇教程不从 ERP 功能清单开始，而是从口径、表结构、事务、并发、幂等、对账和复盘，完整拆解一套可落地的库存流水设计方法。

一、先讲结论：库存余额不是账本，流水才是事实

1. 先把三张表的职责分开

在我参与过的订单、仓储和供应链系统建设中，最容易被低估的设计问题，是把业务单据、库存余额和库存流水混在一起。三者看起来都在描述“库存变化”，实际上承担的是完全不同的职责。

如果订单系统直接修改库存余额，却没有同步记录业务单号、请求号和前后数量，那么这次修改即使当下是正确的，未来也很难被验证。反过来，如果所有查询都实时扫描海量流水，又会把一个简单的“查可售库存”变成昂贵的聚合计算。

因此，我更推荐采用“余额表服务实时读取，流水表保存不可变事实，业务单据提供业务语义”的三层模型。余额表是缓存性质的账面结果，流水表是可以审计的事实记录，业务单据则解释这条事实为何发生。

2. 任何库存动作都要先回答四个问题

正式建表前，我会要求产品、仓库和开发一起确认四个问题。第一，这个动作改变的是实物数量，还是库存状态；第二，动作发生的时间以业务创建时间、仓库确认时间还是系统处理时间为准；第三，同一业务单据是否允许重复执行；第四，发生错误后是撤销原流水，还是追加一条反向补偿流水。

例如，订单锁定通常不会改变仓库里的实物数量，但会减少可用库存、增加锁定库存。销售出库则会减少实物库存和锁定库存。订单取消一般是释放锁定量，而不是凭空增加实物库存。若这几类动作都只用一个 change_qty 字段表示，后续对账很容易把“状态变化”和“实物变化”混为一谈。

建议在设计文档中先写清楚库存公式：

可用库存 = 实物库存 – 锁定库存 – 冻结库存
可售库存 = 可用库存 – 安全库存

期末实物库存 = 期初实物库存 + 入库数量 – 出库数量 + 盘点调整数量

这不是所有企业都必须采用的唯一公式，但必须存在一套明确、可执行、可测试的公式。库存系统最危险的状态，不是公式复杂，而是不同团队各自使用不同公式。

3. 我的核心判断标准：能否还原问题现场

设计库存流水时，我不会先问“字段够不够多”，而会先问：“如果一个 SKU 的账面库存和实物库存相差 7 件，我能否在 10 分钟内还原当天所有相关动作？”如果答案是否定的，就说明流水模型还不合格。

一条合格的流水至少应当能定位 SKU、仓库、业务类型、业务单号、请求号、变化前数量、变化后数量、操作来源和处理时间。对于批次、序列号、货主、库位要求较高的场景，还必须把这些维度纳入唯一定位条件，而不能只依赖 SKU。

二、背景和真实场景：库存差异通常不是一个 SQL 能解决的

1. 一个常见的多系统库存现场

以一个销售型企业的单品为例，商品 SKU-A 在华东仓初始化实物库存 100 件。当天发生采购入库 50 件，订单锁定 20 件，订单出库 12 件，取消订单释放 3 件，盘点发现短少 2 件。若系统正确区分状态和实物动作，最终结果应当是：

此时可用库存为 131 件；如果企业还设置 10 件安全库存，可售库存就是 121 件。很多系统却只保存一个 stock_qty = 131，然后在平台同步时直接把 131 发出去。平台看似同步成功，账务却已经失去“锁定、实物和安全库存”的边界。

在实际排查中，库存差异往往来自多个环节叠加：订单消息重复消费一次、仓库回传延迟、人工盘点调整没有业务单据、退货入库后未经过质检、平台同步读取了旧余额。每个环节单独看都不复杂，但如果没有流水，所有问题最后都会被归结为“库存不准”。

2. 为什么“同步成功”不等于“库存一致”

我经常看到项目验收时把“平台接口返回成功”当成库存同步成功。实际上，这最多只能证明一次网络调用完成。真正的一致性至少包含四层：内部余额是否正确、流水是否完整、仓库实物是否一致、外部平台展示是否在允许时延内接近内部可售库存。

例如，系统在 10:00 将可售库存 8 件同步到平台，10:01 内部又完成了两笔订单锁定，平台仍展示 8 件，并不一定是同步失败，可能只是系统允许 2 分钟的最终一致窗口。但如果 10:10 仍未更新，就应当进入延迟告警。如果内部余额本身是错误的，平台同步越及时，错误扩散得越快。

所以在数据库存与库存流水设计中，我会把“账务一致性”和“渠道同步时效”拆成两组指标，不用一个“同步成功率”掩盖所有问题。

3. 数据分析工具适合做复盘，不适合替代事务库存库

如果团队使用九数云这类数据分析工具做库存经营复盘，合理的定位是连接订单、库存流水、采购、仓库和销售渠道数据，构建库存差异、周转和异常处理看板。它可以帮助业务人员从多维度观察“哪类 SKU、哪个仓库、哪个渠道经常出问题”，但不应成为扣减库存的实时事务数据库。

我的建议是：交易数据库负责毫秒级的条件更新和幂等校验，分析工具负责汇总、切片、趋势和责任定位。二者之间通过稳定的流水数据或数据仓库同步连接，而不是让经营看板直接参与库存扣减。

三、常见误区：看起来能跑，实际上无法审计

1. 误区一：只保存当前库存，不保存前后值

最简单的流水表只有 SKU、变动数量和时间。这种设计在演示项目中可以运行，但在真实系统中很快会遇到问题。假设某 SKU 连续发生入库、锁定、出库和调整四个动作，只知道每次变动了多少，却不知道执行前后余额，就很难判断哪一步开始出现异常。

我通常会在流水中保留至少一组相关状态的前后值，例如 available_before、available_after、locked_before 和 locked_after。它们会增加存储量，但显著降低排查成本。这里的前后值不是让流水表承担余额计算，而是保存当时事务完成后的证据。

2. 误区二：用负数和正数解决所有库存状态

“入库为正、出库为负”只适合描述实物数量变化，不适合覆盖锁定、释放、冻结、解冻等状态转换。若把订单锁定写成负 10、订单释放写成正 10，然后直接累加所有流水，就会得到一个看似正确、实则混淆状态的结果。

更稳妥的做法是把库存变化拆成不同维度，或者在流水中明确数量作用域。可以采用“实物变化量、可用变化量、锁定变化量、冻结变化量”四组字段，也可以设计事件类型映射表。无论选哪种方式，都要让对账程序知道一条事件究竟影响哪个库存口径。

3. 误区三：先查询库存，再在应用层判断是否足够

以下代码逻辑看起来合理，但在并发下不安全：

SELECT available_qty
FROM inventory

WHERE sku_id = :sku_id AND warehouse_id = :warehouse_id;

if available_qty >= request_qty:

UPDATE inventory

SET available_qty = available_qty - request_qty

WHERE sku_id = :sku_id AND warehouse_id = :warehouse_id;

两个请求可能同时读到 10 件库存，然后都判断通过，最终扣减 12 件。真正可靠的方式，是把“库存足够”直接放进更新条件中，并依据受影响行数判断是否成功：

UPDATE inventory
SET available_qty = available_qty - :qty,

version = version + 1,

updated_at = CURRENT_TIMESTAMP

WHERE sku_id = :sku_id

AND warehouse_id = :warehouse_id

AND available_qty >= :qty;

如果更新影响行数为 0，可能是库存不足，也可能是 SKU、仓库或版本条件不匹配。生产代码不能只返回“库存不足”，还应记录失败原因，方便后续区分业务拒绝和系统冲突。

4. 误区四：把人工修正直接写成 UPDATE

当库存出现差异时，直接执行 UPDATE inventory SET available_qty = ... 是最短路径，却是最差的审计路径。它会让余额发生变化，但没有记录调整原因、操作人、审批人和对应盘点单，后续任何人都无法判断这次变化是否合理。

人工修正也应该产生一条或多条补偿流水。原始错误流水不能删除，正确做法是保留原记录，再追加一条“库存调整”或“差异补偿”流水，让两条记录在账面上形成闭环。

5. 误区五：把业务时间和数据库写入时间混为一谈

仓库在 14:00 完成出库，接口因为网络异常在 14:08 才回传。若系统只保存写入时间，日报会把出库归入 14:08；若只保存业务时间，又无法分析消息延迟。至少应区分事件发生时间、系统接收时间和数据库提交时间。

对于乱序消息，还应增加事件版本或业务状态版本。时间戳只能帮助排序，不能单独证明事件先后，因为不同系统的时钟、重试和补发机制都可能造成时间不可靠。

四、专业判断逻辑：先定义边界，再选择技术方案

1. 判断库存模型属于哪一类

库存系统并不是只有一种设计。第一类是简单数量库存，适合 SKU 和仓库维度单一、没有批次和序列号的业务。第二类是状态库存，除了实物数量，还区分可用、锁定、冻结、待检等状态。第三类是可追溯库存，进一步要求批次、效期、库位、序列号、货主和成本批次可还原。

如果业务只是内部办公用品领用，直接采用复杂的批次账本可能增加维护成本；但如果涉及食品、药品、医疗器械或高价值设备，只保存 SKU 总量就无法满足召回、效期和责任追溯要求。

2. 判断一致性要求，而不是盲目追求强一致

库存扣减通常属于强一致场景，但库存展示、营销看板和历史分析不一定需要强一致。架构设计时，我会把动作按风险分级：销售下单和仓库出库需要严格控制，平台展示允许短暂延迟，经营报表则更关注最终完整性。

如果把所有环节都设计成同步强一致，系统会因为外部平台或仓库接口抖动而被拖慢；如果把所有环节都设计成异步最终一致，又可能在核心扣减环节出现超卖。因此应当先识别不可接受的错误，再决定哪些步骤必须在同一事务中完成。

3. 判断是否需要流水重放能力

如果库存规模不大、业务变化简单，补偿流水和定期对账可能已经足够。如果系统拥有多个库存状态、多个仓库和大量异步事件，就需要评估是否支持根据流水重建余额。

支持重放并不意味着任何人都可以随时重算生产库存。重放通常应在隔离环境完成，先得到重算结果，再与线上余额进行差异比对，最后通过审批后的补偿动作修正线上数据。直接在生产库全量重放，可能造成锁竞争、重复扣减和业务查询抖动。

五、数据模型实操：余额表、流水表和幂等表怎么落地

1. 库存余额表的设计

余额表的核心原则是“一行代表一个可核算库存单元”。最简单的唯一键是 SKU 加仓库，但一旦涉及批次、货主或库位，就必须把这些维度纳入唯一定位，否则不同批次的库存会被错误合并。

CREATE TABLE inventory_balance (
id BIGINT PRIMARY KEY,

sku_id BIGINT NOT NULL,

warehouse_id BIGINT NOT NULL,

batch_no VARCHAR(64) NOT NULL DEFAULT '',

owner_id BIGINT NOT NULL DEFAULT 0,

physical_qty DECIMAL(18, 3) NOT NULL DEFAULT 0,

available_qty DECIMAL(18, 3) NOT NULL DEFAULT 0,

locked_qty DECIMAL(18, 3) NOT NULL DEFAULT 0,

frozen_qty DECIMAL(18, 3) NOT NULL DEFAULT 0,

version BIGINT NOT NULL DEFAULT 0,

updated_at TIMESTAMP NOT NULL,

UNIQUE KEY uk_inventory_unit

(sku_id, warehouse_id, batch_no, owner_id)

);

数量字段是否使用整数，取决于业务单位。服装件数可以使用整数，液体、原材料和称重商品可能需要三位甚至六位小数。数据库精度必须提前确定，不能让应用层用浮点数处理库存数量，否则会出现 0.1 加 0.2 不等于 0.3 的精度问题。

我会特别保留 version 字段，即使当前采用数据库行锁，也为未来切换乐观锁或检测并发覆盖预留能力。余额表还应记录最后更新时间，但不能用最后更新时间代替流水时间，它们的语义不同。

2. 库存流水表的设计

流水表建议尽量采用追加写入。除非涉及脱敏或合规处理，已经提交的库存流水不应被业务代码直接修改。对于撤销、冲正和人工修复，追加反向或补偿流水比修改历史记录更容易审计。

CREATE TABLE inventory_flow (
id BIGINT PRIMARY KEY,

sku_id BIGINT NOT NULL,

warehouse_id BIGINT NOT NULL,

batch_no VARCHAR(64) NOT NULL DEFAULT '',

owner_id BIGINT NOT NULL DEFAULT 0,

biz_type VARCHAR(32) NOT NULL,

biz_id VARCHAR(64) NOT NULL,

operation_type VARCHAR(32) NOT NULL,

physical_change DECIMAL(18, 3) NOT NULL DEFAULT 0,

available_change DECIMAL(18, 3) NOT NULL DEFAULT 0,

locked_change DECIMAL(18, 3) NOT NULL DEFAULT 0,

frozen_change DECIMAL(18, 3) NOT NULL DEFAULT 0,

physical_before DECIMAL(18, 3) NOT NULL,

physical_after DECIMAL(18, 3) NOT NULL,

available_before DECIMAL(18, 3) NOT NULL,

available_after DECIMAL(18, 3) NOT NULL,

request_id VARCHAR(128) NOT NULL,

source VARCHAR(32) NOT NULL,

event_time TIMESTAMP NULL,

received_at TIMESTAMP NOT NULL,

created_at TIMESTAMP NOT NULL,

UNIQUE KEY uk_inventory_request (request_id),

KEY idx_inventory_biz (biz_type, biz_id),

KEY idx_inventory_query

(sku_id, warehouse_id, created_at)

);

这里的 request_id 不建议只使用订单号。一个订单可能经历锁定、出库、取消和退款多个动作，因此建议使用“业务单号加操作类型加业务版本”组成幂等键，例如 SO202609160001_LOCK_v1。

3. 幂等记录表应当独立吗

如果幂等逻辑只服务库存流水，可以直接在流水表上建立唯一索引。如果一个请求可能触发多种业务写入，例如同时更新库存、订单状态和积分，则建议单独建立幂等记录表，保存请求状态、处理结果和失败原因。

CREATE TABLE idempotent_request (
id BIGINT PRIMARY KEY,
request_id VARCHAR(128) NOT NULL,
biz_type VARCHAR(32) NOT NULL,
status VARCHAR(16) NOT NULL,
response_body TEXT NULL,
retry_count INT NOT NULL DEFAULT 0,
first_received_at TIMESTAMP NOT NULL,
last_processed_at TIMESTAMP NOT NULL,
UNIQUE KEY uk_request_type (request_id, biz_type)
);

幂等不是“重复请求不报错”这么简单。真正的幂等是：同一个业务动作无论被执行一次还是重试十次，最终库存结果和业务状态都一致，并且系统能够返回第一次成功处理的结果。

六、一次入库、锁定、出库和取消的完整事务链路

1. 入库必须绑定业务单据

入库不是简单地把数量加到余额表。采购入库、调拨入库、退货入库、盘盈入库虽然都表现为数量增加，但它们的质量状态、成本归属和可用时间可能完全不同。

以退货为例，仓库收到商品不代表商品立刻进入可售库存。它可能先进入待检区，质检合格后才转为可用库存；质检不合格则进入不良品库存。若系统在收到包裹时就直接增加可售库存，库存数量可能暂时正确，但销售承诺已经错误。

入库事务至少应包含以下步骤：

1. 校验入库单是否存在、是否允许入库。
2. 校验 SKU、仓库、批次和货主是否匹配。
3. 根据业务单号和操作类型生成幂等键。
4. 锁定或条件更新库存余额行。
5. 写入入库流水，记录前后数量和来源。
6. 更新入库单明细的已入库数量。
7. 在同一事务边界内提交，或通过可靠事件机制完成后续通知。

2. 订单锁定和出库不要合并成一个动作

订单锁定发生在销售承诺阶段，出库发生在仓库实际发货阶段。二者之间可能相隔几分钟，也可能相隔数天。将锁定和出库合并，会让取消订单、拆单、缺货和部分发货变得难以处理。

一笔购买 10 件的订单，可能先锁定 10 件，随后仓库只找到 8 件并完成部分出库，剩余 2 件转为缺货取消。此时应当分别记录锁定 10、出库 8、释放 2，而不是直接写一条出库 8 的流水，否则系统会遗失那 2 件锁定库存的去向。

BEGIN;
— 1. 先锁定库存：可用减少，锁定增加

UPDATE inventory_balance
SET available_qty = available_qty - 10,
locked_qty = locked_qty + 10,
version = version + 1
WHERE sku_id = 10001
AND warehouse_id = 20001
AND available_qty >= 10;

— 2. 检查影响行数

— 影响行数为 0 时，返回库存不足或并发冲突

— 3. 写入锁定流水

INSERT INTO inventory_flow (
id, sku_id, warehouse_id, biz_type, biz_id,
operation_type, physical_change, available_change,
locked_change, request_id, source,
physical_before, physical_after,
available_before, available_after,
event_time, received_at, created_at
) VALUES (...);
COMMIT;

3. 出库时要校验锁定关系

出库不应只判断“可用库存是否足够”，还要判断是否有对应的锁定库存。对于没有预占库存的即时零售场景，可以允许直接从可用库存出库；但对于传统电商订单，出库数量超过锁定数量，通常意味着订单状态链路出现问题。

出库事务可以同时减少实物库存和锁定库存。若仓库回传数量大于锁定数量，系统应进入异常队列，而不是自动把差额当成普通出库。自动放行这种异常，会让库存越错越远。

4. 取消订单的本质是状态回滚，不是库存凭空增加

订单取消时，如果货物尚未出库，通常只需要释放锁定库存：锁定减少，可用增加，实物不变。如果货物已经出库，再发生退款或退货，则要根据退货收货、质检和重新上架结果决定是否增加实物库存。

我建议为取消和退货设计不同的操作类型，即使它们都可能导致“可用库存增加”。取消是订单占用释放，退货是实物回流，二者在财务、仓储和责任追踪上的含义不同。

七、并发、幂等和消息乱序：真正容易出事故的地方

1. 数据库条件更新适合什么场景

对于单仓库、中等并发、强一致要求高的库存系统，数据库条件更新往往是最稳妥的起点。它依赖数据库对单行记录的原子更新，把“数量足够”和“执行扣减”放到一个操作中，避免应用层读写之间出现竞争窗口。

这种方案的限制也很明确：热点 SKU 会让同一行成为竞争点；高峰期大量请求会等待锁；跨仓库、跨库和跨服务事务的处理复杂度会快速上升。因此它不是永远正确的答案，而是复杂度可控时的优先方案。

2. 乐观锁适合冲突可重试的业务

乐观锁通过版本号判断读取期间是否有其他请求更新。如果版本不一致，当前更新失败，业务可以重试或返回冲突。它适合库存冲突相对可控、业务能够接受重试的场景。

UPDATE inventory_balance
SET available_qty = available_qty - :qty,

version = version + 1,

updated_at = CURRENT_TIMESTAMP

WHERE sku_id = :sku_id

AND warehouse_id = :warehouse_id

AND version = :old_version

AND available_qty >= :qty;

乐观锁并不会消除并发，只是把冲突显式暴露出来。若重试次数没有上限，热点商品会形成请求风暴；若失败原因不区分库存不足和版本冲突，业务人员也无法判断究竟是卖完了还是系统太忙。

3. 缓存预扣不是免费的高性能

高并发秒杀或限量活动中，团队常会使用缓存进行预扣。它可以降低数据库热点压力，但必须补齐四类机制：预扣成功后的订单确认、订单超时后的释放、数据库落账失败后的补偿、缓存与数据库之间的定期校准。

如果缓存扣减成功，订单创建失败，而释放消息又丢失，缓存库存会越来越少。相反，如果数据库落账失败但系统误把订单标记为成功，就会形成账面库存和订单事实的不一致。缓存方案的性能优势，必须用消息可靠性、补偿任务和对账机制换取。

4. 幂等键要覆盖业务动作，而不是只覆盖业务单号

同一订单会经历多个库存动作，订单号本身不能作为所有动作的唯一键。一个更完整的幂等键通常包含业务域、业务单号、动作类型和版本，例如“销售单号加锁定动作加明细版本”。如果同一订单支持部分发货，还要把发货批次或出库单号纳入唯一标识。

幂等记录的状态建议至少包括处理中、成功、失败和待补偿。请求第一次成功后，第二次请求不应再次执行库存变更，而应返回原处理结果。对于处理中状态，则要判断是否超时，避免简单重试导致双重执行。

5. 消息乱序需要状态机兜底

事件系统中，消息的发送顺序不等于消费顺序。取消消息可能先于锁定消息到达，仓库出库回传可能先于订单状态同步到达。系统不能只用消息到达时间决定是否执行，而应根据业务状态、事件版本和可逆性判断。

我的处理原则是：可逆动作可以暂存等待，不可逆动作必须校验前置条件；无法判断的事件不自动吞掉，而是进入异常队列。异常队列不是失败日志的垃圾桶，而应当包括原始消息、当前状态、预期状态、重试次数和建议处理动作。

八、对账机制：库存流水不能只写不查

1. 先做余额与流水对账

最基础的对账，是从某个期初时点开始，汇总期间内所有有效流水，计算出理论期末余额，再与余额表中的实际值比较。这个过程看似简单，真正困难的是明确哪些流水进入公式、哪些流水只改变状态。

SELECT
sku_id,

warehouse_id,

SUM(physical_change) AS period_change,

SUM(available_change) AS available_change,

SUM(locked_change) AS locked_change

FROM inventory_flow

WHERE created_at >= :start_time

AND created_at < :end_time

AND status = 'VALID'

GROUP BY sku_id, warehouse_id;

对账时不能只看总数量差异，还应按业务类型拆分。比如某仓库总库存一致，但订单锁定量差异很大，仍然可能导致平台超卖。建议至少输出实物差异、可用差异、锁定差异和冻结差异四个结果。

2. 再做业务单据与流水对账

第二层对账是检查业务单据是否都有对应流水。已确认的采购入库单没有入库流水，说明业务状态和库存账务脱节；存在库存出库流水却找不到有效出库单，说明可能出现了人工脚本、重复消费或脏数据。

这类对账不能只比数量，还要比状态。例如订单已经取消，但仍存在有效锁定流水且没有释放流水，就应当列入异常。订单部分发货时，已出库数量、已锁定数量和待发数量三者必须满足业务规则。

3. 最后做系统库存与仓库实物对账

仓库实物是库存账务的最终约束之一，但仓库盘点数据也有时间窗口和口径。系统在 16:00 生成库存快照，仓库在 16:30 完成盘点，如果期间还有出入库动作，直接比较两个数字必然产生偏差。

正确做法是建立冻结时间点，记录盘点期间发生的业务流水，并将盘点结果回推到统一时点。对于批次库存，还要确保系统和仓库使用同一批次编码规则；否则总数量可能相等，批次分布却完全不同。

4. 对账异常必须分级

不是所有差异都需要立即阻断业务。可以按影响范围和可修复性分级：一级是可能造成超卖、重复出库或监管风险的异常；二级是单据状态未闭环但库存暂未受影响；三级是报表延迟、字段缺失或低风险展示问题。

九、异常修复与流水重放：不要用“改数字”结束事故

1. 常见异常的定位顺序

遇到库存差异时，我不会先执行修正 SQL，而会先锁定差异对象和时间范围。具体顺序是：SKU、仓库、批次和货主；差异发生的时间窗口；余额变化；对应流水；业务单据；消息日志；仓库回传；外部渠道展示。

这样做的原因是，库存差异经常不是在发现时刻产生的。今天发现可用库存少 5 件，可能是两天前重复出库造成的。如果只看当天流水，会把问题定位到错误的时间范围，最终补偿动作还可能制造第二次差异。

1. 记录当前余额快照，防止排查过程中现场继续变化。
2. 冻结相关 SKU 的人工调整权限，重大场景可暂时停止自动扣减。
3. 按库存单元拉取完整流水链路。
4. 按业务单号核对订单、采购单、出库单和盘点单。
5. 检查请求号是否重复、消息是否重试、状态是否乱序。
6. 确认差异属于实物问题、账务问题、同步问题还是口径问题。
7. 形成补偿方案并执行复核。

2. 补偿流水要表达“为什么修正”

补偿流水不应只写 adjust +5。至少需要记录原异常流水、补偿原因、审批单号、执行人、执行时间和补偿前后值。对于自动补偿，还要记录触发规则和任务批次，避免未来把自动修复误判成人工操作。

INSERT INTO inventory_flow (
id, sku_id, warehouse_id,

biz_type, biz_id, operation_type,

physical_change, available_change,

request_id, source,

physical_before, physical_after,

available_before, available_after,

event_time, received_at, created_at

) VALUES (

:id, :sku_id, :warehouse_id,

'INVENTORY_RECONCILIATION',

:reconciliation_id,

'COMPENSATION',

5, 5,

:request_id,

'AUTO_REPAIR',

131, 136,

126, 131,

:original_event_time,

CURRENT_TIMESTAMP,

CURRENT_TIMESTAMP

);

补偿记录中的业务时间可以关联原异常发生时间，但数据库创建时间必须保留实际修复时间。这样既能还原业务时点，也能知道什么时候进行了修复。

3. 什么时候可以做流水重放

流水重放适合以下场景：余额表疑似被人工误改；系统迁移后需要验证余额；大规模数据修复前需要模拟结果；某段时间的消费逻辑存在缺陷，需要评估影响范围。重放的第一步不是写回生产库，而是在隔离环境中计算理论余额。

重放程序要明确三类流水：有效流水、已撤销流水和补偿流水。不能因为某条流水后来被认定错误，就物理删除它；应由状态或反向流水表达其失效关系。重放结果若与线上余额不同，应先输出差异明细，再决定是否生成补偿。

4. 什么时候不建议重放

如果流水本身存在大面积缺失、事件顺序无法确定、业务口径在历史期间发生过变化，直接重放可能得到一个“数学上完整、业务上错误”的结果。此时应先做口径分段、人工确认或从仓库盘点快照重新建立可信期初。

重放也有性能成本。流水量达到数亿级后，全量扫描、排序和状态计算都可能影响分析资源。可以采用按时间分区、按库存单元并行计算、保存周期快照等方式，把重放范围缩小到异常期间和异常对象。

十、性能与可维护性：流水越完整，越要提前设计数据生命周期

1. 先根据查询场景设计索引

库存流水最常见的查询不是全表扫描，而是按 SKU、仓库和时间范围查询，或者按业务单号查完整链路。因此索引应围绕真实查询设计，而不是把每个字段都加上索引。

建议优先评估以下索引：

• SKU、仓库、创建时间：用于拉取某库存单元的时间流水。
• 业务类型、业务单号：用于从订单或出库单反查库存动作。
• 请求号：用于幂等校验和重复请求定位。
• 仓库、事件时间：用于仓库级日结和盘点对账。
• 批次、效期：用于批次追溯和临期库存分析。

如果流水表按月分区，查询条件最好带上时间范围。缺少时间条件的跨分区查询，会让数据库扫描大量历史数据。对于经营分析，不建议直接依赖交易流水实时聚合，可以同步生成日级或小时级汇总表。

2. 流水表要有归档策略

流水是事实记录，不等于所有历史数据都必须永远留在热表。可以根据审计、合规和查询要求，把近几个月数据放在热表，较早数据归档到历史表或数据仓库。归档前必须验证数量、金额、记录数和关键业务单号的完整性。

我建议至少保留周期库存快照。这样查询某个 SKU 一年前的库存，不必从系统初始化以来的第一条流水开始重算。快照不是替代流水，而是给流水重放提供可信的起点。

3. 不要过早分库分表

分库分表可以解决容量和写入压力，但也会带来跨库对账、全局幂等、跨分片查询和数据归档问题。如果每日只有几万条流水，先做好字段、索引、分区和归档，通常比一开始引入复杂中间件更划算。

当出现以下信号时，再评估拆分：热表索引膨胀导致查询明显变慢；单库写入和备份窗口无法满足要求；单个仓库或热点 SKU 产生持续锁竞争；历史查询和实时交易互相影响。架构升级应当由容量和故障数据驱动，而不是由技术名词驱动。

十一、用九数云做库存复盘：分析层和交易层如何配合

1. 适合分析什么问题

当库存流水已经稳定写入后，经营团队通常会提出更复杂的问题：哪些 SKU 经常出现库存差异；哪个仓库的锁定超时最多；哪些渠道的库存同步延迟更高；哪些退货在质检环节停留过久；库存周转下降究竟是采购过量，还是销售预测偏差。

这类问题不适合每天让开发人员临时写 SQL。可以将库存余额、库存流水、订单明细、采购入库、出库回传和盘点结果整理为分析数据集，再使用九数云这类分析工具搭建库存复盘看板。看板的价值不是替代数据库事务，而是让业务人员在统一口径下进行筛选、下钻和横向比较。

数据接入时，我会把事实表和维度表分开。库存流水是事实表，SKU、仓库、渠道、供应商和日期是维度表。这样既能按仓库查看，也能按商品类别、供应商或渠道拆分差异，而不需要每次重新拼接业务表。

2. 建议搭建四类分析视图

第一类是库存健康视图。展示期初库存、入库、出库、调整、期末库存、可用库存、锁定库存和库存周转天数。它适合管理者快速判断库存结构，但必须注明统计日期和库存口径。

第二类是异常追踪视图。展示库存差异 SKU、差异金额、异常等级、首次发现时间、责任环节和当前处理状态。它不应只展示差异数量，还要能下钻到业务单据和流水明细。

第三类是同步质量视图。比较内部可售库存、仓库库存和渠道展示库存，统计同步延迟、失败次数、重试次数和超时订单。这个视图能帮助团队区分“内部账错”和“外部展示延迟”。

第四类是流程复盘视图。观察订单锁定到出库的时长、取消到释放的时长、退货收货到重新上架的时长，以及人工调整占比。它把库存问题从数据结果追溯到流程节点。

3. 看板字段必须带口径说明

“库存周转率”是最容易引发争议的指标之一。有人用销售成本除以平均库存，有人用出库数量除以平均库存，也有人用期末库存直接估算。看板上如果只写“周转率”，不同部门会拿不同公式解读，最终看板越漂亮，争议越大。

我会在指标名称或说明中写清楚统计口径，例如“近 30 天出库数量 ÷ 近 30 天平均实物库存”，并标明是否排除调拨、退货和盘点调整。对于可用库存和实物库存，也要在筛选项附近展示公式，而不是把口径藏在数据模型里。

4. 一个有价值的复盘示例

假设看板发现华东仓库存差异率只有 1.5%，并不算特别高，但进一步下钻后发现，差异主要集中在 20 个高销量 SKU；同时这些 SKU 的锁定超时率达到 11%，人工调整占比也明显高于其他商品。

这时不能简单得出“仓库盘点不准”的结论。更合理的判断路径是：高销量导致订单并发更高，取消和部分发货事件更多，锁定释放链路可能存在延迟；人工调整只是结果，不一定是根因。继续关联消息日志后，如果发现大量释放事件在出库消息之后到达，就应优先修正状态机和事件版本，而不是要求仓库增加盘点频率。

这就是分析工具对库存系统的真正价值：它不替你修改库存，但能帮助你判断应该修改数据库、消息链路、仓库流程，还是库存口径。

十二、不同业务情况下的行动建议与技术取舍

1. 小规模内部库存系统

如果系统只有一个仓库、几百个 SKU、每天几千次库存动作，建议优先采用单库事务、余额表加流水表、唯一幂等键和每日对账。暂时不必引入缓存预扣、消息总线或复杂分库分表。

这个阶段最重要的不是追求高吞吐，而是把库存口径、业务类型和补偿流程建立起来。建议先覆盖入库、出库、锁定、释放、盘点调整五类动作，批次和序列号按业务实际需要扩展。

2. 多仓、多渠道订单系统

当系统同时对接多个销售平台、多个仓库和多个履约渠道时，应将渠道展示库存与内部可售库存分层处理。内部库存先完成账务计算，再按渠道规则扣除安全库存、预留库存或渠道配额，最后异步同步到外部平台。

此时应增加同步任务表、失败重试、超时告警和渠道差异看板。同步任务的幂等键不能只使用 SKU，因为同一个 SKU 会在不同仓库、不同渠道和不同时间产生多次同步任务。

3. 秒杀或极高并发场景

高并发场景可以考虑缓存预扣和队列削峰，但必须接受最终一致性带来的工程成本。缓存中的数量不能被视为最终账务，数据库流水仍然要形成最终事实。活动结束后，应对缓存扣减、订单成功、数据库流水和仓库出库进行专项核对。

如果商品价值高、库存数量少、超卖损失大，即使吞吐量下降，也应优先选择更严格的数据库条件更新或分段库存配额，而不是为了追求峰值 QPS 放松账务约束。

4. 批次、效期和序列号管理场景

批次场景不能只在流水表增加一个 batch_no 字段，还要明确先进先出、效期优先、指定批次出库和批次合并规则。序列号场景则需要一条序列号的完整状态迁移记录，例如在库、锁定、出库、退回、维修和报废。

如果业务需要召回某一批商品，系统必须能从采购批次追到入库仓库、销售订单和最终客户。这个要求决定了流水不能只按 SKU 汇总，也不能在数据仓库阶段才临时补批次信息。

5. 强审计或强监管场景

强审计场景需要保留原始事件、处理事件、补偿事件和审批记录。人工调整应有权限和审批链，流水写入要记录来源系统、操作人、请求号和时间。重要表还应设置访问审计，避免管理员直接修改生产数据却没有痕迹。

取舍是显而易见的：审计字段越完整，存储、归档和权限治理成本越高。但对高价值商品而言，审计成本通常低于一次无法解释的库存事故成本。

十三、从库存流水复盘系统，而不是只复盘库存数字

1. 建议关注八个指标

库存流水的最终价值，不只是把差异记录下来，还要帮助团队持续降低差异发生率。建议至少建立以下指标：

• 库存实物差异率：系统实物库存与盘点库存的差异数量除以盘点库存。
• 可用库存差异率：系统可用库存与业务核算可用库存的偏差。
• 重复请求拦截次数：反映接口重试和消息重复投递情况。
• 库存扣减失败率：区分库存不足、版本冲突、数据错误和系统异常。
• 锁定超时量：反映订单取消、支付失败和履约状态未闭环。
• 异常补偿数量：反映系统自动修复和人工介入的规模。
• 异常闭环时长：从发现异常到完成补偿、复核和关闭的时间。
• 人工调整占比：人工库存动作占全部库存动作的比例。

这些指标要结合业务分组观察。全局平均值可能掩盖热点问题，建议至少按 SKU、仓库、渠道、供应商、业务类型和时间段切分。一个整体差异率很低的系统，可能仍然有一个仓库或一组爆款商品持续出错。

2. 用帕累托方法寻找主要根因

我通常会把异常按根因分类，再做帕累托分析。常见分类包括重复消费、取消未释放、部分发货未闭环、人工调整无单据、批次映射错误、仓库回传延迟和盘点时点不一致。

如果 70% 的差异来自取消未释放，那么增加数据库索引并不能解决问题；如果 70% 的差异来自重复消费，那么优化仓库盘点流程也不是优先事项。复盘应该指导下一轮工程投入，而不是停留在“本次已补库存”。

3. 把“异常处理时长”拆成过程指标

异常闭环时长过长，未必是修复 SQL 写得慢。它可能卡在发现、确认、定位、审批、执行或复核中的任一环节。建议将总时长拆分为：发现延迟、定位耗时、审批等待、补偿执行耗时和复核关闭耗时。

如果发现延迟占主要部分，应增加实时对账或阈值告警；如果定位耗时最长，应完善业务单号、请求号和前后值；如果审批等待最长，应设计低风险自动补偿和高风险人工审批分级；如果复核耗时最长，应自动生成补偿后的对账结果。

4. 复盘报告要回答三个管理问题

第一个问题是，这次差异影响了哪些客户、订单和仓库；第二个问题是，根因属于业务规则、数据模型、事务边界、消息系统还是人工流程；第三个问题是，怎样让同类问题下次被更早发现，或者直接被系统阻止。

只有回答这三个问题，库存流水才真正从“记录工具”变成“系统改进工具”。否则团队每次事故都在补库存、改状态，却没有减少下一次事故出现的概率。

十四、上线前检查清单：从准备到复盘的最小闭环

1. 数据模型检查

• 是否明确实物、可用、锁定和冻结库存的定义。
• 库存唯一单元是否包含 SKU、仓库、批次、货主和其他必要维度。
• 流水是否记录业务类型、业务单号和请求号。
• 是否保存关键数量的变化前和变化后值。
• 数量精度是否符合件数、重量或体积等业务单位。
• 流水是否采用追加写入，避免直接覆盖历史事实。

2. 事务和并发检查

• 扣减是否采用数据库条件更新或可靠的版本控制。
• 是否根据受影响行数判断扣减是否成功。
• 余额更新和流水写入是否处在明确的一致性边界内。
• 同一业务动作是否具备唯一幂等键。
• 重复消息、超时重试和消费中断是否有明确处理状态。
• 热点 SKU 是否有锁竞争、重试次数和队列积压监控。

3. 对账和修复检查

• 是否能按 SKU、仓库和批次执行余额与流水对账。
• 是否能检查业务单据与库存流水的匹配关系。
• 是否区分实物差异、状态差异和渠道同步差异。
• 人工调整是否必须关联审批单或盘点单。
• 异常修复是否追加补偿流水，而不是直接修改余额。
• 是否支持在隔离环境验证流水重放结果。

4. 分析和复盘检查

• 经营看板是否标注库存指标的计算公式和统计时间。
• 是否能下钻到 SKU、仓库、订单和流水明细。
• 是否能区分同步延迟和内部账务错误。
• 是否跟踪异常闭环时长和人工调整占比。
• 是否按根因分类并持续观察异常集中度。
• 是否有明确的月度或周度库存复盘负责人。

5. 最小可行落地顺序

如果团队现在只有一张库存余额表，不建议一次性重构所有库存模块。可以按以下顺序渐进改造：

1. 先冻结库存口径，写出实物、可用、锁定和冻结的计算规则。
2. 新增追加式库存流水表，并为已有库存建立初始化流水。
3. 为入库、出库和订单锁定增加业务单号、请求号和前后值。
4. 将扣减逻辑改为条件更新，并增加受影响行数检查。
5. 建立每日余额与流水对账任务，先输出异常，不急于自动修复。
6. 为取消释放、部分发货和人工调整增加补偿流水。
7. 将稳定的流水数据同步到分析层，搭建库存差异和异常闭环看板。
8. 根据真实异常数据，再决定是否引入缓存预扣、队列串行化或分库分表。

十五、结语：好的库存系统不是永远不出错，而是出错后可解释、可修复

库存系统的终点不是把余额显示成一个漂亮的数字，而是让这个数字经得起追问。业务人员问“为什么是 136 件”，系统应该能回答期初是多少、发生过哪些入库和出库、哪些订单曾经锁定、哪些取消已经释放、哪次盘点产生了调整，以及当前余额是否能由这些事实重新核算出来。

我对库存流水的判断可以浓缩为五句话：余额是结果，流水是事实，对账是验证，补偿是修复，复盘是改进。只做余额表，系统能运行；增加流水，问题可追溯；增加幂等和事务，错误会减少；增加对账和补偿，事故能够闭环；把流水接入分析层，团队才有机会改变流程，而不是反复手工改数。

下一步不需要先购买复杂系统或重做全部架构。先选一个真实仓库和一组高频 SKU，拉出最近 30 天的入库、锁定、出库、取消、退货和盘点记录，尝试用流水重新计算期末库存。若计算结果与余额表不一致，先把差异分类，再决定是补字段、补幂等、补状态机，还是重新定义库存口径。

当团队能够在一次库存异常发生后，快速定位到具体业务单据、请求重试、状态乱序或人工调整，并且通过补偿流水完成修复时，这套库存系统才真正具备架构价值。库存流水不是数据库里的附属日志，而是供应链系统可以被审计、被解释、被改进的事实底座。

UPDATE inventory SET available_qty = available_qty - :qty version = version + 1 updated_at = CURRENT_TIMESTAMP WHERE sku_id = :sku_id AND warehouse_id = :warehouse_id AND available_qty >= :qty;

免费注册

咨询方案

扫码咨询方案