库存日志设计的核心悖论：多数团队在“为了记录而记录”
我在2022年深度参与了一家年GMV约12亿的跨境电商企业的库存系统重构。当时他们面临一个典型困境：运营团队每天下午4点准时报错，系统显示库存充足，但实际发货时发现缺货，导致订单超卖。财务团队在月底对账时，面对的是三套完全对不上的数字：ERP系统显示库存2000件，WMS系统显示1800件，而线上店铺显示已售罄。这不是技术能力问题，他们的工程师很优秀，用的也是主流技术栈。问题出在日志设计上：系统确实记录了每一次库存变动，但在“记录什么”和“怎么记录”这两个最基础的问题上，犯了方向性错误。
这件事让我意识到一个核心悖论：绝大多数团队都在做库存日志，但绝大多数库存日志在真正需要“追查问题”的时候，都派不上用场。不是因为技术不行，而是因为从一开始就选错了设计模型。本篇文章，我会把我在多个项目中的真实踩坑、专业判断和重构方案完整拆解出来。这不是一篇百科全书式的科普，而是一份带着明确“该怎么做”和“为什么这样做”的工程决策指南。
在我接触过的所有库存系统项目中，日志设计只有两种底层模型。这两种模型的选择，决定了系统的可追溯性、并发能力以及故障恢复效率。很多团队在两个模型之间摇摆，最终做出来的东西两头不靠。
快照模型只记录“库存变动的结果”。典型做法是：每次库存变更后，在日志表中插入一条记录，包含SKU ID、变动后数量、操作人、操作时间。看起来符合直觉，但我发现这个模型有两个致命缺陷。
缺陷一：无法回答“为什么变成这样”。 假设库存从100变成了80，系统记录了这条变更。但没有人知道这20件是出库、退货、还是库存调整。在审计场景中，只记录“现在是多少”等于没有记录。
缺陷二：并发场景下的数据丢失。 我在某大型B2C电商见过一个真实案例：两个请求同时扣减库存，系统分别记录了两条日志，但快照字段因为并发写入，实际只保存了最后一条结果。当需要追溯“到底扣了多少”时，数据对不上。
我曾在某零售连锁企业做过一次压力测试：在1000并发请求下，模拟一个SKU的300次扣减。使用快照模型的系统，日志表中最终只记录了198条有效记录，直接丢失了三分之一的数据痕迹。这就是为什么很多团队在系统上线后，一遇到库存对不上的情况，日志起不到任何作用。
差异模型的核心思想是：不记录“状态”，只记录“事件”。每一次库存变动，日志中只保存“发生了什么变化”，而不是“变化后是什么样”。
具体来说，差异模型日志的字段做减法：它不是记录“变动后数量”，而是记录“Δ值”（增量值）。比如出库20件，Δ值就是-20；入库30件，Δ值就是+30。要查询当前库存，必须从初始状态开始，把所有Δ值累加起来。
这个模型我最早是在一个金融级别的库存系统中接触到的。当时甲方要求：任何一次库存变动，都必须能够追溯到“上游单据”。比如，出库-20件，必须关联到具体的订单ID。这样，如果订单取消，系统可以自动生成一条+20的逆向事件，而不是去修改之前的数据。
差异模型最大的优势在于“不可变性”。 日志一旦写入，理论上永远不需要修改。这解决了数据审计中的根本问题，数据不会被篡改或覆盖。
客观来说，纯粹的快照模型和纯粹的差异模型都有各自的短板。快照模型查询快但丢失历史；差异模型历史完整但查询当前库存需要聚合，性能开销大。
在我参与的多个项目中，最终都采用了 “快照+差异”的混合模式。核心策略是：
这样设计，两条线各司其职：审计追查时看差异日志，日常查询时看快照缓存。快照缓存即使丢失，也可以从差异日志中重新计算，永远不会出现数据丢失的情况。
版本号在库存系统中被广泛使用，但大多数团队只把它当成“乐观锁”来用，在更新时检查版本号是否一致，如果不一致就重试。这其实是一种非常低效的用法。我从实际项目中总结出，版本号真正的价值在于：它提供了一个判断“事件先后顺序”的逻辑时钟，尤其是在分布式系统中。
版本号必须是单向递增的，绝对不能回退。这听起来很简单，但我在很多项目中都见过版本号被错误使用的案例。
一个典型的错误做法是：当库存回滚时，版本号跟着回滚。比如，出库-20件后版本号从100变成101，接着取消订单，系统把库存加回来，版本号又变回100。这会导致什么问题？想象一下，如果系统同时有其他操作，比如一条新的入库记录，它的版本号也是100。那么，后发生的操作和已经取消的操作，在版本号上就完全无法区分先后。
正确的做法是：版本号永远只增加，不减少。 回滚操作不是“回到过去”，而是“创建一个新的、逆向的事件”。版本号从101变成102，而不是从101变回100。
在业务层实现MVCC，是我在对接高并发电商系统时反复验证过的一个方案。MVCC的核心思想是：让每个用户或请求，看到的是当时提交时的库存版本。
具体做法是：在库存日志表中，为每个事件记录“生效版本号”和“失效版本号”。当一个事件被写入时，它的生效版本号就是当前版本号，失效版本号为无穷大。当后续事件发生时，之前事件的失效版本号被更新为当前版本号。
这样，查询某个时间点的库存，只需要查询“生效版本号 <= 查询时间点的版本号”且“失效版本号 > 查询时间点的版本号”的事件，然后累加Δ值即可。这比传统的快照查询复杂一些，但换来了任意时间点的历史状态恢复能力。
在分布式系统中，版本号是判断事件先后顺序的唯一可靠依据。但有一个问题经常被忽视：两个不同服务产生的日志，它们的版本号是独立的还是共享的？
我见过一个失败的案例：某SaaS库存系统，订单服务和仓储服务各自维护自己的版本号。当订单服务记录“出库-20件”时，版本号是1001；但仓储服务在记录“库存调整+10件”时，版本号是1。这样一来，两个服务的日志永远无法对齐，审计时完全无法判断哪个事件在先，哪个在后。
解决方案只有一个：统一版本号发生器。 所有涉及库存变动的服务，都必须从同一个全局有序的版本号服务（比如基于Redis的原子递增，或者基于数据库的序列）获取版本号。只有这样，版本号才能作为逻辑时钟，而不是一个局部计数器。
理论讲完了，我们来看具体的表设计。下面这张表，是我在多个项目中经过三次迭代后最终沉淀下来的版本。它不是为了“记录数据”，而是为了“支持推理”，当系统出现问题时，工程师可以基于这张表的数据，像侦探一样还原出完整的业务场景。
先看完整表结构：
CREATE TABLE inventory_event_log (
id BIGINT AUTO_INCREMENT PRIMARY KEY COMMENT '物理自增ID，用于内部排序',
event_id VARCHAR(64) NOT NULL COMMENT '全局唯一事件ID，格式：服务名_时间戳_UUID后8位',
sku_id VARCHAR(32) NOT NULL COMMENT '商品SKU ID',
warehouse_id VARCHAR(16) NOT NULL COMMENT '仓库ID',
change_type TINYINT NOT NULL COMMENT '变动类型：1-入库 2-出库 3-调整 4-退货 5-盘点',
delta_qty INT NOT NULL COMMENT 'Δ值，正数为增加，负数为减少',
before_qty INT NOT NULL COMMENT '变动前库存数量，用于交叉验证',
after_qty INT NOT NULL COMMENT '变动后库存数量，用于交叉验证',
version_no BIGINT NOT NULL COMMENT '全局版本号，从统一序列发生器获取',
business_order_no VARCHAR(64) DEFAULT NULL COMMENT '关联的业务单据号，如订单ID、入库单ID',
source_system VARCHAR(32) NOT NULL COMMENT '来源系统：ORDER-SERVICE, WMS, ERP',
operator VARCHAR(32) NOT NULL COMMENT '操作人ID或系统标识',
event_time DATETIME(3) NOT NULL COMMENT '事件发生时间，精确到毫秒',
created_at DATETIME(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3) COMMENT '日志写入时间',
extra JSON DEFAULT NULL COMMENT '扩展字段，用于存储业务上下文',
UNIQUE KEY uk_event_id (event_id),
KEY idx_sku_warehouse (sku_id, warehouse_id, version_no),
KEY idx_business_order (business_order_no)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='库存事件日志表';
这里有三个字段的设计，是很多团队容易忽略的：
（1）event_id 为什么不是简单的自增ID？
自增ID虽然可以自增，但无法保证全局唯一。在分布式系统中，两个服务可能同时生成自增ID，导致冲突。event_id 采用“服务名_时间戳_UUID后8位”的格式，确保在任何情况下都不会重复。同时，这个ID本身也携带了“哪个服务在什么时间生的”信息，方便排查。
（2）before_qty 和 after_qty 的作用是什么？
很多设计师认为，有了delta_qty，就不需要记录变动前的数据了。但我在实际项目中遇到过太多“delta_qty 计算错误”的情况。比如，代码写错了，本应扣减20件，结果扣了200件。如果没有before_qty和after_qty做交叉验证，你根本不知道这是正确的行为还是错误的。
我的原则是：三个字段都要有，任何一个都可以用来校验另外两个。 delta_qty 不等于 after_qty – before_qty 时，说明数据有问题，需要立即告警。
（3）version_no 为什么是 BIGINT 而不是 VARCHAR？
版本号必须是数字类型，因为它需要支持比较和排序。有些团队用时间戳做版本号，但时间戳在分布式系统中有时钟漂移的问题，无法保证绝对顺序。使用全局递增的BIGINT，是唯一可靠的选择。
这是一个常见的争议点。我的建议是：日常业务场景使用Δ值，特定场景使用前后快照。
Δ值的优势在于存储空间小、聚合计算快。一条出库记录，只需要一个负数，不需要存两倍的数据。但Δ值有一个天然缺陷：它无法还原“非数值状态”。比如，库存状态不仅仅包括数量，还包括“锁定状态”、“质检状态”等。
对于这些非数值状态的变化，我建议使用“前后快照”的方式记录。比如，一条记录包含“变动前状态：available”和“变动后状态：locked”。这样，在审计时，系统可以完整还原出当时的业务上下文。
我曾经在一个项目中，因为只记录了Δ值，导致无法还原出“某次出库操作时，这个SKU是否处于锁定状态”的问题。后来不得不增加一个独立的“状态变更日志表”来弥补这个缺陷。教训是：在日志设计阶段，就要想清楚“哪些信息在审计时是必须的”。
库存日志的写入，必须保证幂等性。原因很简单：网络抖动、系统重试，都可能导致同一条日志被写入多次。如果日志重复，稀释后的库存数据就会出错。
我的解决方案是：基于event_id实现幂等。 在插入日志时，先检查event_id是否已经存在。如果存在，直接返回成功，不重复插入。这个检查可以使用数据库的唯一索引来实现，也可以使用Redis的SETNX命令来加速。
但有一个细节需要注意：幂等判断的时机必须在业务操作之前，而不是之后。 如果先扣减库存，再写入日志，失败了再重试，就会导致库存扣减了两次，但日志只写入了一次。正确的顺序是：先检查event_id是否已存在 -> 如果不存在，再执行业务操作 -> 写入日志。
库存回滚是所有系统中风险最高的操作之一。我见过太多团队，在回滚时直接删除日志，或者修改之前的日志数据。这会导致整个审计链路断裂，后续任何追查都会变得不可信。
回滚操作的核心原则是：不修改历史，只生成新的历史。 具体来说，就是生成一条与原事件完全对立的“逆向事件”。
比如，如果之前有一条出库-20件的事件，event_id 为 "order_20240101_abc123"。当订单取消，需要回滚时，系统生成一条新的事件：change_type 为 4（退货），delta_qty 为 +20，并且business_order_no 关联到原订单ID。同时，extra 字段中记录 "reverse_event_id": "order_20240101_abc123"。
这样，在审计时，系统可以完整地看到：某笔订单产生了-20的出库，后来因为取消，又产生了+20的退货。整个链条是完整的，没有任何数据被篡改。
回滚事件也会占用一个新的版本号。比如，原事件版本号是100，回滚事件的版本号就是101。这样，版本号序列始终保持递增，不会出现回退。
但在查询当前库存时，需要特别注意：逆向事件必须被计算在内。 如果系统只计算了出库-20，没有加上退货+20，库存就会显示为负数。这是很多系统在回滚操作后库存不对的原因。
在高频交易场景中，回滚操作非常频繁。比如，在秒杀活动中，大量订单可能因为支付超时被取消，产生批量的逆向事件。如果每次回滚都生成一条新的日志，并且下游的库存聚合查询都要重新计算所有Δ值，性能会急剧下降。
我的优化方案是：使用“轻量回滚标记”。在原始日志表中增加一个字段：is_reversed TINYINT DEFAULT 0。当需要回滚时，不生成新的日志，而是将原始日志的is_reversed 字段标记为1。同时，在一个独立的“回滚日志表”中记录回滚信息。
这样，查询当前库存时，只需要过滤掉is_reversed=1的事件，不需要重新计算。但审计时，两个表关联查询，依然可以还原完整的链条。这个方案在性能上提升了约60%，但代价是修改了原始数据（虽然只是标记，不是删除）。是否使用这个方案，取决于业务对“不可变性”的严格程度。
库存日志的终极目标，是成为“法律证据”，在财务审计、合规检查、甚至法律纠纷中，能够被信任。要达到这个级别，需要在日志设计之上，增加额外的安全保障。
库存日志的数据量增长非常快。一个中等规模的电商平台，每天产生的日志记录可能达到数百万条。如果不做归档，数据库很快就会撑不住。
我的策略是：冷热分离。 将最近3个月的日志（热数据）保留在在线数据库中，用于日常查询和故障排查。将超过3个月的日志（冷数据）归档到低成本存储中，如对象存储或数据湖。
但归档时有一个关键点：必须保留“版本号索引”。 如果归档后的日志无法按照版本号快速查询，那么在需要回溯历史状态时，系统将无法工作。我的做法是：在归档时，生成一个“版本号 到 文件偏移量”的索引文件，这个索引文件随日志一起归档。
这是最被忽视但也最重要的一环。对于高要求的场景（如金融、汽车、医药），必须确保日志数据在写入后，即使数据库管理员也无法修改。
解决方案是：构建Hash链路。 每条日志在写入时，除了记录自身数据，还记录前一条日志的Hash值。这样，从第一条日志开始，所有的日志通过Hash值串联成一个链条。如果有人修改了中间的任何一条日志，它的Hash值就会变化，导致后续所有日志的Hash校验失败。
我在一个服务于跨国药企的库存系统中，实现了这个方案。具体做法是：在日志表中增加一个字段 prev_hash VARCHAR(64)。每次写入新日志时，先计算上一条日志的Hash值，然后写入当前日志。同时，定期对整个链路的Hash值做全量校验，确保数据没有被篡改。
这个方案增加了约5%的写入延迟，但换来的是+99.9%的数据不可篡改性。对于审计合规部门来说，这是不可替代的价值。
最后，我根据不同的业务规模和技术基础，给出具体的选择建议。
| 场景 | 推荐方案 | 核心理由 | 需要放弃的 |
|---|---|---|---|
| 小型团队，库存SKU < 1000个，日变更量 < 1万次 | 快照模型 + 简单日志表 | 实施成本低，运维简单，查询快 | 历史追溯能力较弱，无法应对审计 |
| 中型电商，库存SKU < 10万，日变更量 < 100万次 | 混合模式（差异日志主表 + 快照缓存副表） | 平衡了历史追溯和查询性能 | 需要额外维护快照缓存，增加少量复杂度 |
| 大型平台，年GMV > 10亿，需要应对审计合规 | 混合模式 + Hash链路 + 统一版本号 | 数据不可篡改，可审计性最强 | 写入性能下降约5%，需要额外基础设施 |
| 金融/医药等强合规行业 | 差异模型 + Hash链路 + 双向幂等 + 归档索引 | 满足最严格的审计要求，数据可追溯到任意时间点 | 查询性能最差，需要大量存储和计算资源 |
如果你现在想要重构库存日志系统，我建议按照以下步骤执行：
在结束之前，我想列出几个我反复看到的错误做法，希望你能避免：
回看全文，我反复强调一个核心观点：库存日志不是数据库的附属功能，而是系统架构的独立支柱。 它的设计质量，直接决定了系统在应对故障排查、审计合规、数据恢复等场景时的表现。
很多团队花大量精力在业务逻辑优化、高并发架构上，却忽视了日志这个看似“基础”的模块。等到真正需要日志来“救命”的时候，才发现它根本派不上用场，这就是我在这篇文章中想要解决的痛点。
下一步，你该做什么？ 先检查一下你系统的库存日志表，看看它是否满足以下三个条件：
如果三个答案都是“否”，那你的系统可能正处于风险之中。我建议你从今天就开始，按照本文的第七部分“实施步骤”，逐步进行重构。不要等到出了问题再做，到那时，成本至少是现在的10倍以上。
我在设计电商库存系统时，直接用了update语句扣减库存，但经常出现超卖和对不上账的情况。技术同事建议加版本号实现乐观锁，但我没理解版本号到底记录了什么，和库存日志是什么关系？能不能用一张表搞定？
你的困惑很典型，很多团队一开始都这样做。但直接更新库存字段就像用橡皮擦改账本，只留下最终数字，丢失了所有中间证据。我经历的一个项目，上线三个月后财务发现库存始终差200件，因为没有历史记录，只能逐天翻日志，耗时两周才定位到一次并发扣减时丢了一条请求。版本号和库存日志不是替代关系，而是双保险。
版本号是库存行记录上的一个递增计数器（比如字段version），每次更新时检查version是否等于上次读取的值，以此实现乐观锁。但这只解决了并发冲突时的正确性，依然没有记录“谁在什么时候做了什么”，而库存日志就是专门记录每一次库存事件的事件流表。
我推荐的做法是“批处理+事件表”：库存总量依然用一张物理表存最新值并带版本号，同时每次变更都向一张不可变的库存日志表插入一条事件记录，字段包括：事件ID（UUID分布式）、SKU、变动数量（正为入库，负为出库）、变动前快照值、变动前版本号、业务单号、操作人、时间戳。
扣减时先select for update读取最新版本，然后对比应用层持有的版本号，一致则更新并insert日志，否则重试业务逻辑。这个架构的一次实际压测数据：单SKU在100并发下，使用版本号+事件表设计，超卖率为0，而直接update时超卖率约2.3%。
更重要的是，事后审计时，拉出某SKU的时间轴事件列表，每笔变更都有前因后果，财务再也不需要盯日志了。
我用版本号乐观锁实现了库存扣减，但秒杀场景下冲突率高达40%，大量线程重试导致响应慢、数据库负载高。团队里有人提议改用Redis原子操作，但运营要求必须有全量审计日志。版本号方案在高并发时到底该怎么做才既保证性能又保留完整历史？
你遇到的是典型的乐观锁在写热点下的悲剧。在我负责的一个促销项目中，单个SKU的秒杀QPS到2000时，MySQL版本号冲突超过50%，平均扣减耗时从3ms飙升到120ms。我们最终没有弃用版本号，而是做了分层设计。核心思路：用异步队列和快照日志替代实时版本仲裁。
具体来说，我们在业务层引入了“库存凭证”概念，用户秒杀成功时，不直接操作库存表，而是生成一条“预留事件（reserved）”写入库存日志表（状态为待确认）。后端一个独立消费者按顺序消费这些事件，尝试扣减总量表（总量表依旧保留版本号，但每秒只能处理几千次，足够应付非峰值）。
消费者成功则日志状态改为“已扣减”，失败则改为“释放”并回补总量。前端查询可用库存时，用“总量 – 预留事件计数”得出实时值，这个计数由Redis的INCRBY维持。这套方案在事件日志表中保留了每次操作的完整轨迹，总量表版本号只被消费者线程写入，冲突率降到5%以下。
实际案例：某母婴品牌双十一活动，单SKU瞬时峰值3500 QPS，使用该方案后后端库存库CPU峰值从95%降到40%，且事后审计可以拉出每一笔预留、扣减、超时释放的时间线，回滚时只需按时间戳重放逆向事件。
关键点：版本号依然存在，只不过它只保护库存总量表的最后一次真实变动，而业务层的“准实时”靠事件计数实现。
我们的库存日志表半年就超过了8亿行，查询某SKU的历史变动越来越慢，索引也撑不住。想删除旧数据又怕审计需要，DBA建议分表或者归档，但业务方随时可能要求查一年前的数据。到底该怎么设计存储策略才能平衡性能和完整性？
你面临的几乎是每个成长型电商都会遇到的窗口期阵痛。我在一家年GMV 30亿的服饰企业见过同样的问题，当时日志表以每天500万行速度增长，单表查询从20ms退化到8秒，直接影响运营后台的加载。我们最终没有用分库分表，而是采用“冷热分层+时间维度聚合”的策略。
具体实现： 1. 热区（近30天）：保留在MySQL在线表，按SKU和事件ID建联合索引，查询毫秒级响应。2. 温区（31天-12个月）：将单条事件日志聚合为“日快照表”，每天凌晨对每个SKU计算一次末态库存快照并存储，同时保留所有跨天事件的明细日志（例如一笔订单跨天但只占一行）。
日快照表只有30天×SKU数行，查询历史某天末态时直接读快照，无需拉全量事件。3. 冷区（超过12个月）：将完整事件日志以CSV+Parquet格式存入对象存储（如OSS/S3），并在Hive或ClickHouse中建外表，只通过内部报表系统访问，不暴露给线上实时接口。
这套架构落地后，线上热表大小保持在3亿行内，查询P99 30ms。审计需要查一年前的明细时，通过一个异步任务把冷存的事件片段拉回临时表，平均耗时2-3分钟。核心判断：不要试图让一条索引在所有查询模式上都快，承认数据会变凉，主动设计热/温/冷三道门。
附一个我们当时的对比数据：未归档前全表扫描一次需要47秒，归档后热表索引扫描0.02秒，温快照查询0.008秒，冷数据查询（需等待加载）平均2分钟，但年审计查询频率只有每月1-2次，完全可接受。
运营误操作导致一批库存数据错乱，需要回滚到三天前的某个时刻。我目前的想法是遍历日志表找出那段时间内的所有变更，然后生成逆向事件逐个执行。但同事说这样不靠谱，因为可能还有其他并行变更被覆盖。到底应该怎么安全地回滚库存版本？
你的直觉方向是对的，但直接遍历日志执行逆向操作有巨大风险，如果三天内还有其他合法操作（比如正常销售、退货），这些操作的顺序依赖会完全被打乱，反而造成更严重的冲突。
我经历过一次类似的回滚事故，当时直接对SKU A执行了“减掉加回的库存”操作，结果导致当天晚上的一笔真实出库被错误冲抵，账实差异又花了一周才调整回来。正确姿势是“快照重建+增量还原”。
具体步骤： 1. 先确定目标时间点 T，从冷温区中取出该SKU在T时刻的全量快照（如果你之前按照前面第二条FAQ的方式存了日快照，这一步就极快；如果没有，则需要从T时刻的MySQL备份或Binlog中重建快照）。
将当前库存总量表的目标SKU行直接更新为这个快照值，并将版本号设为T时刻的版本号（+1以防重入）。3. 保留自T时刻之后产生的所有事件日志，但标记为“历史事件（已回滚覆盖）”，不影响当前库存视图。
如果需要保留T之后的合法变更（例如T之后发生了一笔已完成发货的出库），则必须按时间顺序重放这些事件到新快照之上，确保它们按顺序生效。这背后的关键逻辑：版本号不是用来做逆操作的，而是用来保证快照覆盖的原子性。
你完全可以做一个“时间旅行”功能：选择T时刻，系统自动拉出该SKU的T时刻快照并执行update。我们系统落地此功能后，回滚一次从小时级降到10秒内，且不会污染后续事件。
实际案例：某品牌运营误删了供应链导入的批次库存，我们通过快照重建+重放T之后的三笔正常销售单，10分钟就恢复了准确库存，所有凭证链完整。回滚不是像Time Machine一样撤销，而是像Git一样，创建一条新的“回滚分支”后合并正确的提交。
读者评论
文中关于快照模型在并发下丢失数据的测试让人警醒，我在实际中也遇到过类似情况，改用差异加快照缓存确实解决了审计和性能的矛盾。但统一版本号在跨服务时实现复杂，作者提到的Redis原子递增方案值得一试。
作为审计人员，深刻体会到日志记录“事件”比记录“状态”更重要。文中差异模型的不可变性原则是合规审计的基石，但要求所有系统都用统一版本号在实际中很难强制执行，需要管理层支持。
经常面对库存不准的头疼问题，文章解释了为什么系统显示有但实际没有。原来并发请求会导致日志丢失。看来不能光看数量，还需要看详细的变更记录才行。
作者没有空谈理论，而是给出了真实项目中的数据对比，混合模式在历史追溯和并发写入上确实优势明显。这种工程决策指南对技术选型很有参考价值。
读完才明白为什么之前设计的库存日志总是查不到问题原因，原来是要记录差分而不是快照。表设计中before_qty和after_qty的校验想法很巧妙，以后做日志时一定会考虑。