库存数据对不上，这事每天都在中小企业里发生。我做过几年数据运维，见过太多人一听到库存出错就登录数据库，找到库存表，直接UPDATE一把。运气好的改对了，运气不好把负数改没了账面却对不上，运气更差的把人家正在出库的单子给锁住了。今天这篇内容，我按自己踩出来的思路重新梳理，不绕弯子，用四种症状类型、六步排查动作、三类恢复手段，帮你把“数据库存异常排查”这事做成一张可复用的排查地图。
一、先把核心结论说清楚
库存数据出错，表面看是数据库里某个数字不对，实际是业务链路、接口同步、事务控制、并发写入四个环节当中的某一个断了。所以排查的第一原则是：先判断是哪一类问题，再决定要不要碰数据库。不是所有库存异常都是数据库的锅，直接改库往往是下下策。
我统计过自己接触过的32个库存异常案例，结论如下：约45%的问题出在业务链路，比如单据重复提交、状态未更新；约30%的问题出在接口同步，比如ERP和电商平台之间漏单、重复推送；只有约20%的问题真正出在数据库层，比如事务没提交、死锁、字段被触发器改写；剩下约5%是历史脏数据被人为改坏了。一个非常扎心的现象是：一线团队接到报障后，超过一半的人第一反应是查数据库，而不是查业务单据链路。
这个顺序反了。库存库存，先有“库”再有“存”。账实不符的根源往往在“存”的过程里，而不是“库”的表结构里。后面我会用一个实际案例把你领一遍完整排查路径。
二、真实场景：一次库存异常处理的完整回放
2023年的时候，我服务过一家做快消品的电商团队。某天上午十点，运营发现一款SKU在电商后台显示还剩120件，但仓库实物已经没了，线下ERP里却显示还有230件。三个数字，三个口径，谁都不服谁。
当时的IT是个刚来两个月的同事，头一反应就是登录数据库，跑了一条查询，发现数据库里显示还有230件库存，觉得数据库没问题，把问题丢回给运营。运营不服，说电商平台接口实时扣减，平台上明明120件；仓库也不服，说自己实物都发完了。三方僵持到下午三点，最后拉我过去一起看。
我没有先查库存表，而是顺着出库单走了一遍。结果发现一个非常典型的问题：仓库发货后，出库单在ERP里生成了，但状态没有从“待出库”更新成“已出库”，导致WMS减了库存、ERP没减、电商平台通过接口同步时读到的又是另一个状态。问题不在数据库，而在订单状态更新这个业务动作断了。数据库里的数据没有“错”，它只是忠实地展示了一个没有完成的业务流程。
这个案例里真正花掉的时间只有40分钟左右，但前面从上午十点到下午三点，将近五小时都在“改数据”和“改错了再改回来”之间打转。纯手工改数，越改越乱。
三、四个常见误区：为什么你越修越乱
1. 误区一：库存表数字不对，就认为是数据库故障
数据库不会自己把数字改掉。除非你遭遇了硬件故障、异常断电或人为提权操作，否则一张库存表的数字一定是业务动作写入的结果。库存表只是结果表，流水表才是过程表。当你觉得“库存表错了”，大概率是写入库存表的那个逻辑或流程错了。不要一开始就怀疑数据库系统本身，先怀疑业务写入方。
2. 误区二：出错了就手工UPDATE库存表
这是我在中小企业见到最频繁的操作。某次一个财务因为库存账面多了20件，手工执行了一条UPDATE语句直接把库存减掉20。问题是，这20件货其实早已出库，只是出库单没审核。财务手动改了库存表，等到仓库补审出库单时，库存又被系统自动减了20，直接变成负库存。手工改数就像一张“创可贴”，贴错了反而会把新伤口贴上。
3. 误区三：只看当前库存数字，不追溯历史流水
库存余额只是一个快照，判断它是否正确的唯一方法是把流水表的每一笔出入方向重新加总一遍。但很多人一上来就看“当前值”，不看“怎么变成这个值”的。正确的做法是先确认“最后一次准确的时间点”，再检查之后每一笔流水是否都符合预期方向。
4. 误区四：查了日志就算排查了，没有形成结论闭环
我见过有人查完慢日志，发现一条SQL执行了三秒，就断定是性能问题，从此开始优化索引。优化完，响应时间降到200毫秒，但库存依然对不上。因为那条SQL本来就是后台批量任务在跑，三秒并不影响业务正确性。排查的终点不是“发现一个可疑点”，而是“找到因果链条”，能解释清楚为什么数字变成这样，并且验证通过。
四、专业判断逻辑：先通业务链路，再下钻数据库
我总结的排查逻辑，简单说就是“两端追：从现象端往上游追，从单据端往下游追”。不要从数据库入手，从业务现象入手。
一套完整的判断顺序是：识别症状类型 → 回溯业务链路 → 定位接口状态 → 验证数据库事务 → 确认根因 → 安全恢复。前面三步不花多少时间，但能过滤掉六成以上的假数据库问题。
1. 第一步：先判断库存数据出错属于哪一类
把问题先分个类，见下表。
| 症状类型 | 典型表现 | 优先排查方向 |
|---|---|---|
| 账实不符 | 账面有货实物没货，或实物有货账面没货 | 出库单状态、盘点记录、报损报溢单 |
| 多系统不同步 | ERP、WMS、电商后台三个数不一样 | 接口日志、推送记录、重试机制 |
| 数据库异常报错 | 查询超时、更新锁死、死锁日志 | 慢查询日志、锁等待、事务隔离级别 |
| 历史数据被改动 | 某一天之后库存数字突然异常 | 变更日志、触发器、手工改数记录 |
2. 第二步：沿业务链路回溯，找到“最后一次正确”的时间点
这一步是最容易被跳过的，也是信息量最大的一步。你要带着四个问题去看：
- 库存最近一次确认准确是什么时候？
- 从那之后，发生了哪些入库、出库、盘点、调拨、退货动作？
- 这些动作里，哪些单据的状态是“未完成”的？
- ERP、WMS、电商平台之间的接口调用记录里，哪些是成功的，哪些是失败的，哪些是重试的？
把这条路走完，通常能找到至少一个断点。
3. 第三步：进入数据库层做定向验证
这时候才应该打开数据库工具。我是按下面这个顺序来查的：
- 查库存余额表、库存流水表、订单明细表三者的数量关系是否勾稽。
- 查事务日志和死锁报告，确认是否有提交异常或锁竞争。
- 查慢查询日志，确认是否存在大事务、锁表时间过长、索引失效。
- 查触发器和存储过程，确认是否存在隐式改写库存的代码。
一个非常重要的提醒：不要在不知道“正确值”应该是什么的情况下执行任何UPDATE语句。如果你还没通过流水推算出应该的值，那就还没到改数据的时候。
4. 第四步：判断是“数据问题”还是“代码/配置问题”
同为库存异常，修复方式完全不一样。
数据问题：比如某业务员手动导入了一张错误单据，导致库存被多加了一次。这种情况在业务系统里做“冲销”或“红冲”即可，不需要改数据库。
代码/配置问题：比如库存扣减逻辑没有加事务，导致并发出库时超卖扣减，出现负库存。这种情况要改的是代码逻辑或数据库隔离级别，而不是数据本身。只改数据不改代码，同样的错误明天还会再来一遍。
5. 第五步：快速恢复，但必须留痕
恢复原则上优先走业务单据，次选接口重新推送，最后才考虑数据库层修正。顺序很重要：能用业务单解决的，不要动接口；能用接口解决的，不要动数据库。数据库修正作为最后手段，必须走审批、必须有备份、必须有记录。任何一次手工修正，都要能回答“谁在什么时间、因为什么原因、把哪个值从什么改成了什么”这四个问题。
6. 第六步：从“救火”到“防火”，建立长效机制
只闭环一次异常意义不大，要闭环“产生异常的原因”才算结束。建议按这个方向去推进：
- 库存流水表只增不改，余额必须由流水汇总生成。
- 接口增加幂等控制，避免重复推送导致库存重复扣减。
- 建立每日对账任务，自动比对ERP、WMS、电商平台三端库存。
- 设置负库存预警、大额变动预警、夜间异常写入预警。
- 数据库做定期备份，并且每季度做一次真实的恢复演练。
五、具体案例与数据观察：三种典型场景的修复对比
1. 场景A：接口重复推送，库存被扣了两次
某零售企业，线上线下双渠道销售，ERP和电商平台通过中间表同步库存。某天一款商品线上可售库存显示为0，但实际库存还有15件。查下来发现：该商品当天被用户下单三次，每次下单时ERP的库存扣减接口被调用了两次，扣了6件。为什么调用两次？因为中间表的推送状态字段没有在第一条消息处理成功后立即更新，消费者服务重试机制被触发，导致同一条消息被消费了两次。解决方案：在消息消费端增加唯一键约束和幂等校验。这种场景在代码层做修复，数据本身不需要动。
处理耗时约一天，其中定位花了三小时，代码改动和验证花了四小时，其他时间都耗在等业务方确认上。
2. 场景B：出库单状态未更新，库存被两头算
一家建筑企业的故事。仓库在WMS系统里已经发货，但ERP的出库单没有审核，导致WMS扣减了库存，ERP没有扣减。对账时两边永远差着一截。这个问题的root cause其实是流程设计缺陷：仓库在WMS发货是一回事，ERP里出库单审核是另一回事，两套系统之间没有强约束。正确的做法是在WMS发货完成时，自动触发ERP出库单审核，而不是依赖人工到ERP里再点一次。
此案例处理耗时两天，其中重新梳理流程和同步历史数据各占一天。
3. 场景C：数据库事务未提交导致的假象
有一回查一个库存数据异常，表面看起来非常诡异：数据库中余额表显示库存为80，但将所有流水加总后却是120。差了40，方向一致，每笔流水看起来都正常。查了事务日志才发现，有一个事务执行了UPDATE扣减40，但一直未提交，随后被另一个进程回滚了。这个未提交的数据，在某个被快照隔离的读取会话里被看到了，造成账面虚减。这不是“并发写错”问题，而是事务隔离级别配置和连接池使用不当的问题。
解决方案是调整数据库连接池的默认隔离级别，并开发侧增加事务超时保护。
4. 一个很有说服力的数据观察
我把过去一年经过手的库存异常案例做了一个小统计。在有能力完整回溯流水、并且确认“最后一个正确节点”的案例中，平均定位耗时比直接查库的案例少42%，恢复准确率也要高很多。原因并不复杂：一旦知道“哪里是对的”，就知道“哪里开始错的”，中间隔着的那笔流水就是问题所在。这个规律在几乎所有账实不符场景中都成立，也是我强烈建议把“流水加总”作为校验基准的原因。
六、不同情况下的行动建议
1. 如果问题属于“单据状态异常”
这类问题的特征是账面库存变化方向与业务实际不一致，比如实物出了货但系统没扣减，或者实物入了库但系统没增加。绝大多数情况是单据停留在了“中间状态”。行动建议：找出所有状态为“待审核”“待出库”“待同步”的单据，逐个确认其是否已经实际完成。对已经完成业务动作但状态未更新的单据，执行状态流转即可，不要动库存表。
2. 如果问题属于“接口传递不一致”
你在ERP看到的库存，和电商平台看到的库存不一致，这是典型的接口同步问题。行动建议：第一步查接口调用日志，确认是否出现“成功返回但业务方未收到”或“失败后重试导致重复写入”的情况；第二步检查消息消费端是否有幂等控制；第三步检查两边的库存更新字段是否有中间映射转换错误。这类问题比单据状态稍微复杂，因为涉及两套系统，排查时要记住一个原则：以源头系统的流水为准，以消费端的落库结果为核查对象。
3. 如果问题属于“数据库性能或锁冲突”
特征是库存表本身数据正确，但业务人员反馈打开库存查询页面非常慢，或者出库操作偶发失败。这种情况的排查重点不在数据内容，而在数据库引擎层面。行动建议：查数据库的死锁日志、锁等待超时配置、慢查询日志、索引使用情况；同时检查是不是存在大事务，长时间占用行锁导致阻塞。这种问题通常要在代码层面做事务拆分、把大事务改成小事务，以及在数据库层面优化索引结构。
4. 如果问题属于“历史数据被异常修改”
特征是你找不到任何业务单据能解释这次库存变化，但流水记录里就有那么一笔不明不白的调整。这种情况要优先排查触发器和后台定时任务，确认是否有隐式改写库存表的逻辑。如果确认是人为手工修改，就要从管理层面补齐“变更审批流”和“变更记录表”。没有审计痕迹的库存表，是一个随时可能爆炸的火药桶。
七、不同情况下的取舍
做数据恢复的时候，一定有机会成本。你需要判断：当前库存的准确性和恢复速度，哪个对业务更重要。
1. 补单 vs 改数：优先走业务路径
如果业务链路还在，只是状态没流转，那么把流程走完是最安全的做法。这个方向成本低、可追溯、对账时也说得清楚。只有业务单据不存在或已经无法重建时，才考虑直接改数据。因为改了数据虽然今天能把库存对上，但将来审计时可能说不清楚为什么会有一笔直接变更。该约束一定要有：直接改数必须有审批，必须备份，必须留痕。
2. 临时恢复 vs 根治：短期先业务可用，中期要推动根因修复
在大促期间，系统在扛流量，这时候发现库存异常，通常没有时间慢慢查。建议先用最快的路径做临时恢复，保证前台可售库存不至于超卖或断卖。比如先把有问题的SKU在电商后台置为下架，等流量低峰期再来排查根因。这个取舍的内涵是：大促期间的“快”远比“准”重要，而平时运营期间的“准”远比“快”重要。
3. 手动改数 vs 开发功能：一劳永逸的路径是开发而不是手工
如果一个库存数据的修正动作在你这里频繁出现，每一次都靠手动执行SQL来救火，那么你应该停下来想想：为什么不开发一个“库存修正单”功能，让业务人员在系统里发起修正、走审批流、系统自动更新库存表并留痕？前期开发成本看起来比手工多，但发生十次异常之后，这个功能的成本就回来了。
八、三个“不要碰”的时刻
最后想分享三个我亲身总结的“不要碰数据库”的时刻。这些时刻很容易被误判为需要立即改库，但实际操作上，越过这些时刻直接改数据，几乎都会留下后患。
1. 不要碰：还没找到“最后一次正确时间点”时
如果你还说不清库存从什么时候开始不对的，说明你对这个异常根本还没有判断依据。贸然改数只会把原本可能还完整的流水链条弄得更乱。如果把排查比作破案，时间点就是全案的地基。连地基都没打，就急着砌墙，只会越砌越歪。
2. 不要碰：没有备份时
很多中小企业的数据库没有开启自动备份，或者备份任务经常失败但没人关注。在确认备份可用之前，任何数据库层的写操作都是在打一场没有后援的战斗。一旦改错了，连回退的机会都没有。
3. 不要碰：正在大促或业务高峰时
大促期间执行库存表的UPDATE操作，很可能触发行锁或表锁，进一步拖垮正在运转的业务系统。这时候应该先做业务侧降级，比如下架商品、关闭渠道，等流量平稳后再修复。不要因为一个数字的小问题，导致整个业务系统不可用。
| 时刻 | 风险 | 正确做法 |
|---|---|---|
| 未确定“最后一次正确时间点” | 改错方向，丢失因果链条 | 先追溯流水，找到错误起点 |
| 没有可用备份 | 异常回滚无门，修复后无法自证 | 先做备份，再做变更 |
| 业务高峰期间 | 引发锁冲突，放大负面影响 | 先业务降级，后窗口期修复 |
九、结语：排查清单是开始，不是终点
库存数据准不准，不只是IT一个部门的事，它同时受业务操作规范、系统架构设计、接口稳定性、数据库基础运维水平四个维度影响。IT能修好一次异常，但只有业务、开发、运维三方都动起来，才能真正消灭下一次异常。
你现在可以做的第一件事，是把你平时最常见的库存异常症状对到第二部分那张分类表里，看它属于哪一类，然后按第六部分的行动建议执行。另外，强烈建议把“流水加总==余额”作为例行检查加入你的每日对账任务。只要流水不被破坏，库存表的任何异常都是可以被解释、被修复、被预防的。
如果这篇文章能帮你在下一次面对库存数据异常时，少走一次弯路，少改一次数据，那它就有价值。请把这份排查思路转发给团队里的开发、运维、仓储和相关业务人员，让大家都有一套共同的排查语言，这才是从根本上缩短定位时间最有效的方式。
常见问题解答（FAQ）
1. 数据库存异常排查时，为什么先别急查数据库？第一步应该做什么？
我是公司IT，每次库存数据对不上，第一反应就是打开数据库直接看库存表，但经常越查越乱。想请教有经验的人，在动SQL之前，有没有一套能够快速缩小范围的排查顺序？到底应该先查业务单据还是先查数据表？
一个自己踩过的坑：有次工厂反应某SKU账面库存比实物多出300件。我直接查库存表，发现最后一笔更新记录是三天前，数值没错。又去查流水，发现这三天累计出库400件，但库存表根本没有减。后来才发现，问题出在ERP的接口回调时漏了一条出库单，数据库本身完全正常。
所以我的第一建议是，库存数据异常时，先不要急着打开数据库，先做三件事：第一，确定异常范围，包括涉及的SKU数量、发生时间、哪个仓库；第二，找到库存最近一次准确的时间点，也就是你或业务人员能拍胸脯保证“这个时候账面是对的”的那个点；
第三，从该时间点开始，把所有出入库单据按时间顺序排列，和系统库存余额做对照。这个过程不需要写SQL，只需要在业务系统里拉两张表：期初库存和期间单据流水。为什么要先走这一步？因为库存表只是一个“结果”，它被无数个业务动作更新。
如果直接查数据库，你看到的是某个瞬时的值，却看不到这个值是怎么一步步变成这样的。而单据流水的顺序一旦对了，80%的问题都能在业务层暴露出来，例如重复提交、单据被作废后仍继续占用库存、跨天调拨单在途未确认等。我在处理过的几十次库存异常里，真正由数据库层面导致的比例不到两成。
大多数是业务单据状态和库存余额表不同步。因此，先查单据流，再查库，能帮你把精力花在最可能出错的地方。如果单据流完全对得上，再考虑数据库的事务、锁和SQL逻辑。
2. 多系统（ERP、WMS、电商平台）之间库存不同步，如何快速定位哪个系统是源头？
我们公司同时用ERP、WMS和电商平台，订单发货后库存经常不一致，三个系统的开发都说是别人的问题。每次出问题都要开会扯皮，有没有办法通过某些数据特征，一下子判断到底哪个系统的库存数据才是错的？
多系统库存不同步的本质，是同一份库存语义被多个系统重复存储和修改。你不需要精通三个系统的代码，只需要抓住一条主线：实物库存是唯一的锚点。我建议按下面的步骤做，通常30分钟能锁定源头。第一步，把实物盘点数作为基准。在业务不繁忙的时间，对差异商品做一次突击盘点。
然后分别记录ERP、WMS、电商平台对该SKU的当前库存数。谁与实物差异最大，谁最可疑。这不是绝对准确，但能帮你排除掉至少一个系统。第二步，对比各系统的“最后变更时间”。库存数据在哪个系统先变，哪里就是触发点。
比如WMS已经完成发货过账，时间是14:02，而ERP生成的销售出库单时间晚到15:10，或者根本没有，那么ERP大概率是消费接口失败的那一方。这时要去查接口同步日志，重点看是否有“报文解析失败”、“重试次数超限”等记录。第三步，看“库存跳变”。一个健康的系统里，任何库存变化都应该对应一张业务单据。
如果某个系统里库存数在某一秒发生了变化，但你看不到对应的单据，那这个变化大概率是手工改库、接口重放或者程序Bug导致的。跳变所在的系统，就是源头。我遇到过最典型的场景是“双写”：ERP和WMS各自在本地保存一份库存，并且通过API双向同步。订单在WMS发货后，WMS扣减本地库存，同时通知ERP扣减。
如果通知失败，ERP的库存就不变，两边自然出现差异。要解决这类问题，不能只定位某一次是谁错，更要在架构上改为“单一事实来源”，其他系统只读或通过消息队列异步订阅，这是后话。给你一张判断表：差异类型，系统A比实物多、系统B与实物一致，则优先查A的扣减逻辑；
两边都比实物多，但多出的数量相同，可能是接口重复推送；一边多一边少，且总和等于实物，往往是两个系统用了不同的扣减时点。这张表能帮你在和开发沟通时直接点出方向，减少互相推诿。
3. 数据库没报错、日志也正常，但库存数据就是不对，可能是什么隐蔽原因？
我们系统日志没有异常，数据库也没死锁，但库存余额就是比流水算出来少了几十件。我把相关SQL都看了一遍，没找到问题。这种“看不见摸不着”的错误到底是怎么产生的？有什么方法能把它揪出来？
这种“隐形”库存异常，往往不是数据库本身的故障，而是应用层或者数据写入顺序出了偏差。我把过去几年排查中遇到过的高频原因列出来，你可以逐一对照。第一，库存余额表和流水表不是原子写入。很多程序先更新库存余额，再插入流水记录。如果第二步失败，库存变了，流水没记。
从数据库角度看没有报错，因为事务被提前提交，或者两条语句根本没在同一事务里。验证方法很简单：把库存余额的变化和流水明细做一次全量比对。我常用这条SQL思路：按SKU分组求和库存流水中的变动数量，再与库存余额表相减，差异不为零的就说明存在“无流水变更”。第二，并发扣减导致“丢失更新”。
代码可能是先查询当前库存，判断充足后，再更新库存。问题是两个请求同时读到库存100，分别扣10和20，后提交的会把原来的值覆盖掉，最终库存可能变成80而不是70。数据库不会报死锁，但数据就是错了。
检查办法是打开数据库的通用日志或者binlog，看这两条update的先后顺序和值，如果后执行的update基于旧值，基本可以确认。第三，缓存异步刷新覆盖新值。有些系统为了性能，把库存放到缓存里，扣减后异步写回数据库。如果写回操作没有版本号或者时间戳判断，旧缓存值可能把新值覆盖。
这种情况最常见于秒杀、促销场景。排查时，重点看库存变化记录中是否存在“时间戳倒退”的更新，即数据库中的修改时间早于上一次修改时间，但值却不同。第四，触发器或数据库事件被忽略。有时建了触发器，在库存表更新后自动去修改另一张汇总表。如果触发器有误或已经失效，会导致汇总表和明细表不一致。
检查方式很简单，在测试库里执行一次插入和更新，观察所有相关表的变化，或者直接查询information_schema中的触发器定义。我的经验是，遇到这种隐形错误，不要试图通过人肉读代码找出所有可能。
更高效的做法是搭建一个“库存对账任务”：每天定时运行一个脚本，计算流水汇总并与余额对比，不一致时输出SKU和差异值，同时截取该SKU当天对库存表的全部DML操作。有了这些数据，最多半天就能定位到具体代码行。
4. 库存数据已经错了，如何安全修复而不引发更大问题？
业务部门天天催，说库存差很多，我差点直接执行update把数量改对。后来听一位前辈说直接改库会破坏审计，还可能被其他程序覆盖。那么正确的修复流程应该是怎样的？有没有一套标准步骤能让数据快速恢复，又能避免踩雷？
直接执行update改库存余额，是我见过的风险最高、后患最大的操作。因为你只改了一个数字，却破坏了数据的一致性：没有对应的流水，没有操作记录，没有源代码逻辑。下次对账时，这个无源变更会让问题更隐蔽。所以，修复库存数据必须遵守“先有流水、后有余额”的原则。第一步，先做备份和快照。
在修复前，将相关库存表、流水表的所有记录导出保存，至少保留一份包含操作前数据的SQL文件。没有备份之前，任何操作都不允许执行。这不是流程形式，而是万一修错了唯一能回退的稻草。第二步，优先走业务调整单。大多数ERP、WMS系统都有“盘点”和“库存调整单”功能。
你可以在系统里创建一个盘盈或盘亏单，把差异数量录入，审核后系统会自动生成一条库存流水，同时更新余额。这种方式有单据、有审批、有流水，审计上完全合规，而且后续任何报表都能解释清楚。第三步，只有在业务单据无法覆盖的极端情况下，才考虑直接更新数据库。
这时需要满足四个条件：有审批记录、有操作前备份、有变更说明文档、执行后立即补写一条库存调整流水。补流水很关键，你可以在库存流水表中插入一条“手工调整”类型的记录，并注明原因单号。这样余额和流水重新匹配，对账才能通过。第四步，修复完成后需要验证。
验证不只是看库存数对不对，还要看两条规则：一是流水汇总变动数量等于余额改变值；二是修复后的库存不能出现负数（除非业务允许）。我建议写个校验脚本，每次修复后自动跑一遍。最后，也是最重要的一点：修复完要追根因。如果是因为接口漏单导致，就去修接口的重试机制；如果是因为并发，就去改代码加锁或幂等。
否则这次改回去，下次还会错得更厉害。我把这个总结成一句话：修数必须先修流水，治标一定要治根。
读者评论
文章说的先查业务链路再碰数据库，确实是运维里最容易被忽略的原则。我遇到过好几次库存对不上，最后都是单据状态或接口重复推送导致的，直接改库只会越改越乱。
曾经手滑UPDATE库存表改错了，后来花了两天对账才恢复。看到文章里那个财务手工改库存导致负库存的案例，简直感同身受。流水加总验证这个办法值得记下来。
作为运营，经常遇到ERP、WMS和电商平台三个库存数字不一致的情况，文章里的案例几乎就是日常翻版。最怕IT上来就说数据库没问题，最后发现是出库单没审核。这种排查思路应该推广。