智能MES 的工单下发延迟：从 3 秒压到 300 毫秒要动哪几层

工单下发慢是 MES 里最容易被抱怨又最难定位的问题。工人点了下发，等三秒才看到任务，这三秒里发生了什么，往往没人说得清。

先拆链路

一次下发通常经过：前端提交、应用层校验、工单号生成、BOM 与工艺路线展开、设备与人员分配、写库、消息推送、终端刷新。七段里任何一段慢，体感都是慢。

最常见的三个瓶颈

第一，工单号生成用了数据库序列或者锁表。高峰期并发一上来，全卡在这一个点上。改成预分配号段或者雪花算法，这一段能压到毫秒级。

第二，工艺路线展开是 N 加 1 查询。一个工单展开十几道工序，每道工序查一次物料、查一次设备、查一次工时，几十次往返。改成一次性批量查回来在内存里组装，这一段能降一个数量级。

第三，终端刷新靠轮询。三秒轮询一次，用户点完正好错过一轮，就得等下一个周期，平均体感延迟一秒半。改成服务端推送，这一段基本归零。

排序很重要

不要同时改三处。先加链路埋点，量出每段实际耗时，改最慢的那一段，再量。我见过的项目里，改了第一处之后原本的第二名往往会变成新的瓶颈，顺序错了会白干。

一个容易忽略的点

终端侧的刷新逻辑比服务端优化更影响体感。同样的后端延迟，增量刷新比全量重绘快一个数量级。如果终端是浏览器，先看有没有在做无谓的全表重渲染。

目标值怎么定

不追绝对值，追分位。P50 压到 300 毫秒以内，P99 控制在 1.5 秒以内，比平均值好看更有意义——抱怨的永远是 P99 那批人。

本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。

先加链路埋点量出每段耗时再动手，改最慢的那一段，改完再量。同时改三处多半会白干，因为第一处改完之后原来的第二名会变成新瓶颈。目标盯分位不盯均值，抱怨的永远是尾部那批人。

工单号用数据库序列这条命中率极高，高峰期全堵在一个点上。我们改号段预分配后这一段直接到毫秒。N 加 1 展开也是常见坑，批量查一次比循环里逐条查强太多。

七段拆得对，我再加一段：终端刷新。很多现场卡在最后一公里，工位屏是轮询的，五秒一次，前面压到 300 毫秒也被这五秒吃掉。改成服务端推送或者长连接，体感差别比优化数据库还明显。