妙手ERP性能改造：十万级列表加载

2026 年 2 月 11 日，妙手ERP 完成列表性能改造：订单、商品、库存三类十万级数据列表的首屏加载时间从 8.6 秒降到 1.9 秒，筛选与排序响应稳定在 400 毫秒以内。改造覆盖全部用户，不需要升级套餐。

数据一多，系统就会变慢，这几乎是所有 ERP 的通病。妙手ERP 在 2025 年 9 月做过一次用户侧的耗时埋点，发现单店铺 SKU 超过 8,000 个的团队，打开商品列表的平均等待时间为 8.6 秒，其中 62% 的时间花在前端渲染而不是查询。“慢不是某一个模块的问题，是整条链路都在还债。”妙手ERP 技术负责人郑柏川在压测复盘会上说。

三段耗时：查询、传输、渲染

改造先把耗时拆成三段分别度量：数据库查询、网络传输、前端渲染。查询段的问题是全表扫描与缺少复合索引，传输段的问题是字段过多，渲染段的问题是一次性插入上万个 DOM 节点。三段各自的优化手段不同，混在一起谈优化只会互相掩盖。

查询段按常用筛选组合建立复合索引，把跨表关联改为预聚合宽表，宽表按小时增量刷新；传输段把字段裁剪到列表实际展示的 24 个，其余按需拉取；渲染段改为虚拟滚动，只渲染可视区域的 40 行。

实测：1.9 秒与 400 毫秒

压测使用 12 万条订单、3.2 万个 SKU 与 8 个仓库的库存数据，在 4 核 8G 的环境下进行。首屏加载从 8.6 秒降到 1.9 秒，翻页响应从 2.4 秒降到 180 毫秒，组合筛选从 5.1 秒降到 400 毫秒，导出 5 万行的耗时从 96 秒降到 22 秒。

大促期间的真实表现同样被记录：2025 年黑五当天，峰值并发查询为每秒 1,240 次，第 99 分位响应为 780 毫秒，没有出现超时页面。相比之下，改造前同规模的压测中第 99 分位为 4.6 秒，超时率为 1.8%。

缓存与一致性：快不能靠猜

宽表与列表缓存都设了明确的有效期与失效条件：订单状态变化时主动失效对应分片，库存变动按 SKU 失效，其余情况按 5 分钟过期。界面上会显示数据的最后刷新时间，用户知道看到的是几点的数字，不会把缓存当成实时。

一致性校验每天凌晨执行一次，抽样比对宽表与原始表的记录数与金额合计，差异超过 0.01% 时告警并触发重建。上线两个月内触发过两次重建，原因都是平台侧补发了历史订单，重建耗时分别为 6 分钟与 9 分钟，期间列表仍可读，只是标记为旧数据。

对使用者的三个变化

第一，筛选条件可以叠加到五个而不再明显变慢，运营习惯从先筛店铺再筛状态，变成一次筛完；第二，导出的等待时间缩短，月结时不必再挑夜里跑；第三，列表支持记住上次的筛选与列宽，换电脑后需要重新设置一次。

深圳 3C 卖家运营负责人林嘉禾说：“以前查一个异常单要等五六秒，现在基本是点完就出来，一天下来省的时间比想象中多。”系统同时保留了简化模式，弱网或旧设备可以关闭虚拟滚动，用分页换取更低的资源占用。使用者的感受集中在三处：翻页不再等转圈，筛选条件叠加后结果仍然即时，导出移到后台队列后可以关掉页面去做别的事。2026 年 1 月的大促期间，单日订单峰值 38 万单，列表页未出现超时，慢查询告警 2 条，均为第三方物流回传延迟导致。团队把首屏 2 秒、交互 500 毫秒写进了监控基线，超过基线自动记录慢请求样本。性能不是一次性工程，基线立起来之后，每次发版都要跑一遍对比。下一步计划把列表默认时间范围从 90 天收窄到 30 天，减少无效查询；导出任务会增加进度条与完成通知。团队内部有个共识，性能优化要先量再改，改完再量，中间不靠感觉。监控基线已经接入发版流程，首屏超过 2 秒或交互超过 500 毫秒的版本不允许进入生产，这条规则比任何一次专项优化都更能守住体验。慢请求样本会保留 7 天，方便复现。基线数据每周自动生成一份趋势图，发给技术与业务双方。

性能改造已在全部版本生效，无需额外配置。若列表仍明显偏慢，可在设置页查看当前店铺的数据量与索引状态，数据量超过 20 万的店铺建议开启按站点拆分视图，把单次查询范围压小。