WMS 用了一年越来越慢：数据库、RF、归档，5 个拖慢元凶

先说结论：WMS 用了一年越来越慢，十次有九次跟服务器配置没关系。真正的元凶就五个：历史单据表膨胀、RF 无线网络掉链子、没有归档策略、波次任务堆积、定制报表拖垮数据库。按我下面这套排查清单走，一到两周就能救回来。这个坑我见过三次，三次都是同一个剧本。

2024 年 3 月，Rancho Cucamonga 一家 3PL 仓找到我。12 万平方英尺，日均 8000 单，WMS 上线 14 个月。拣选员跟我抱怨：RF 枪每次扫完条码点确认，要等 5 到 8 秒才有反应。一个人一天扫 2000 多次，等于每人每天光等系统就耗掉将近 3 个小时。老板的第一反应是加服务器，厂商报价 2.8 万美金。我去现场看了一圈，服务器 CPU 常年跑在 30% 上下，内存也还富余。问题根本不在硬件。

无独有偶。2023 年 11 月，Fresno 一家电商品牌仓，旺季前客服查一张历史单据，页面要转圈 40 秒。客服主管差点在旺季前把系统换了。最后我们花了 6 天做归档和索引优化，查询回到 2 秒以内，换系统的事再没人提。

这两个项目救回来之后，我把排查过程固化成下面这套清单。五个元凶，按命中率从高到低排。

元凶一：历史单据表膨胀，这是 WMS 变慢的最大头

WMS 的核心交易表——收货单、拣选任务、波次记录——上线第一年没人管，行数从几十万涨到几千万。很多 WMS 的查询没有做分页，一查就是全表扫描。数据量翻 10 倍，查询时间可不是翻 10 倍，是翻几十倍。

怎么确认是不是它：找你们的数据库管理员或者 WMS 厂商技术支持，查三张核心表的行数和体积。单表行数超过 500 万、且从来没做过归档的，基本就是它。这个检查 10 分钟就能出结果，先做这个。

急救动作分四步：

先全量备份，再动任何归档操作。备份完抽查 20 张历史单据能正常打开，备份才算有效。
把已完成超过 13 个月的单据移到归档表。注意，归档不是删除——财务审计要查账，归档表必须能查，只是平时不进主查询。
归档完立刻重建索引、更新统计信息。这一步很多人漏掉：表瘦下来了，数据库的执行计划还按胖的时候走，等于白干。
归档后让一线员工实测：扫码确认、查历史单、跑波次，三个高频动作都回到 2 秒以内才算过关。

仓库机房里闪烁的服务器机柜

元凶二：RF 无线网络，慢得最冤的一个

这个坑我见过三次，每次老板都先怀疑软件，最后都是无线网络。仓库的 AP 部署是按"空仓"状态规划的，等货架立起来、货物堆满，信号死角就出来了。RF 枪在两个 AP 之间来回漫游，每次切换丢包重传，反映在屏幕上就是"转圈"。

排查方法很土但有效：拿一台 RF 枪，沿着拣选路径完整走一圈，记录每个区域的信号强度和漫游切换次数。重点看三个地方：高位货架底层（金属货架屏蔽信号）、冷库门口（温差导致设备异常）、装卸月台（AP 少、面积大）。

2024 年 6 月，Ontario 一家 8 万平方英尺的电商仓，拣选区中间两排货架底层的 RF 枪频繁掉线。走了一圈发现：那两排货架是旺季前临时加的，AP 还按原来的布局，信号被新货架挡得只剩一格。加了 2 个 AP、把漫游灵敏度调高一档，掉线率从每天 40 多次降到 2 次以内。硬件一分钱没多花——AP 是从闲置的办公区拆过来的。

修复动作：

信号弱的区域加 AP 或者调整 AP 朝向，加完之后重新做漫游测试，漫游切换时间要压到 100 毫秒以内。
把 RF 枪的漫游灵敏度调激进一档，让它早点切到信号强的 AP，别在弱信号上死扛。
检查信道干扰：仓库里如果有私搭的无线摄像头、蓝牙设备，抢的都是 2.4G 信道，该清的清掉。

元凶三：没有归档策略，表迟早还会胖回去

元凶一是急救，元凶三是治本。很多公司归档做完一次就不管了，一年后表又胖回去，慢的毛病卷土重来。这不是技术问题，是没人把归档写进制度。

分步做法：

定保留策略：交易类单据保留 13 个月，日志类数据保留 6 个月，策略要财务和运营一起签字，别 IT 自己定。
把归档做成定时任务，每季度自动跑一次，跑完自动发邮件报告归档行数和释放空间。
指定责任人：每次归档谁执行、谁验收，写进运维手册。没人负责的制度等于没有制度。

元凶四：波次和任务堆积，越积越慢

未完成的波次、卡住的任务单越积越多，WMS 每次分配任务都要先扫一遍待办池。Fresno 那个仓最严重的时候，待分配任务堆了 400 多个，其中一半是三个月前的僵尸任务，早就没人管了，但系统每次还傻乎乎地全扫一遍。

修复动作：

每天下班前，待办池必须清零。清不掉的任务，当天就要有人认领原因。
卡住超过 24 小时的任务自动发告警给主管，别等堆成山才发现。
每季度 review 一次波次模板：SKU 结构变了、订单结构变了，波次规则还按上线那套跑，本身就是堆积的源头。

元凶五：定制报表把数据库拖慢

财务要毛利报表、运营要时效报表，IT 图省事直接连生产库跑大查询。早上 9 点全仓开工，报表也在跑，数据库直接被拖死。这个我见得太多了，报表一跑，全仓 RF 枪一起转圈。

解法只有一条：报表不许直连生产库。要么走只读从库，要么导到数仓，大报表一律凌晨定时跑，白天只看结果。已经上线的报表，一个一个过：连的是哪个库、几点跑、跑多久，全列出来，不合规的限期整改。

算一笔账：加硬件 vs 做优化

反常识的判断说在前面：系统变慢第一反应加硬件，十次有九次是错的。慢的原因不在算力，在数据和习惯。硬件能买，习惯买不来。

再算一笔隐性账：Rancho Cucamonga 那个仓，30 个拣选员，每人每天等系统 3 小时，按加州仓库时薪 22 美金算，一天就是 1980 美金打了水漂，一个月近 4 万。2.8 万的服务器升级款，够发一周的"等待工资"。而归档优化只花了 5 天人力，等待时间直接清零。这笔账，老板看完当场就批了优化方案。