Performance

报表能正常显示一页筛选结果，导出相同范围却明显更慢。流程已经使用流式工作簿写入器，批次大小和写入器配置自然成为排查方向。

沿数据提供层继续检查，发现每个输出批次都会重新进入列表分页流程：计算总数、执行分页查询、转换这一批数据，再追加到工作簿。文件在逐批写入，数据库执行却不断重新开始。

本次本地修复让导出拥有独立的执行生命周期。下文依据本地测试和受控只读比对说明已完成的部分；修复包尚未部署，生产 HTTP 提速也尚未验收。

先统计语句执行次数

列表页需要一段结果，有时还需要总数来计算页码。全量下载需要读完本次选中的结果，再生成完整文件。

旧实现把每个写入批次绑定到新的分页操作，反复支付计数和分页 …

一次生产构建生成了数 MB JavaScript。完成拆包后，应用入口文件的压缩体积明显下降。两个数字都没有回答实际问题：未登录用户要下载多少代码，登录页才能进入可用状态？

一套经过脱敏的企业单页应用暴露了这个差异。原始构建在启动阶段同步注册数十个路由页面和完整组件库。第一轮优化大幅缩小了入口 chunk，也就是构建工具生成的一份代码块；这份文件却不再包含首屏路由、共享依赖和对应样式。若直接把入口体积当成结果，就会高估优化幅度。

最终方案把路由级懒加载和 Vite 构建清单预算结合起来。预算同时覆盖应用入口、指定首屏路由，以及从这两个根节点可达的全部静态 JavaScript 和 CSS 依赖 …

一个分页业务页面只返回约 10 KB 数据，却需要 27.49 秒。响应体很小，基本可以排除网络传输是主要瓶颈；但浏览器耗时本身还不能说明延迟来自页面渲染、应用代码，还是数据库。

真正有用的证据是：一次页面请求会执行两条高成本 SQL，一条用于计算分页总数，另一条用于取得当前十行数据。数据库统计显示，计数 SQL 平均约 21.3 秒，读取约 448 万个缓冲块；数据 SQL 还需要 7.8 至 9.0 秒。两者相加，几乎完整解释了前端观测到的耗时。

原查询在知道用户实际需要哪些订单之前，就先构造了多个派生数据集：对大范围流转记录执行窗口排序，聚合明细和质检记录，最后才按组织、项 …

一个订单状态页面在测试环境正常，生产环境的入库、出库和各节点数量却全部显示为 0。页面列表能看到大量订单，数据库也确认近期业务数据存在，因此页面显示的“0”是汇总请求未及时成功返回后的默认值，与实际数据不符。

旧接口为了统计数量，分别发起多次超大分页查询，把明细加载到 Java 后再分组。每次分页还会额外执行 count SQL。一次页面刷新最终串行触发多条重查询。

测试库数据量很小，这种实现仍能在很短时间内返回；生产流转记录规模大几个数量级，同样的查询需要十几到二十多秒，多项统计串行后超过页面等待时间。前端没有明确失败态，于是保留初始化的 0，看起来就像生产没有订单。

两套 …

一个 WMS 波次计划列表查询一页数据需要约 6 秒。这篇文章记录实际排查路径：从应用日志拿到真实 SQL，检查现有索引，测试并回退无效索引，最后验证新的 SQL 执行结构。

文中的环境和业务标识均已脱敏，SQL 结构、耗时数据和判断过程来自实际排查。

页面需要查询波次主表，关联明细与出库单，聚合 OMS 订单号和 Homebase，关联创建人、修改人信息，并查询装车时间，最后按创建时间倒序返回 50 条。

日志中的关键筛选条件是修改时间范围、组织和项目条件，同时按照创建时间排序。

问题就在这里：SQL 在确定页面最终需要的 50 个波次前，已经开始展开明细、聚合并排序。