窗口函数需用partition by order_id和order by event_time、event_id为物流订单打序号，确保单订单内状态按时间可追溯；lag/lead配合coalesce处理null，用于精准识别状态跳变；max(event_time) over (partition by order_id)替代子查询提升性能。
窗口函数怎么给物流订单按时间排序打序号
物流订单的状态流转必须依赖时间先后，ROW_NUMBER() 是最直接的工具，但容易错用：比如没加 PARTITION BY order_id 就直接 ORDER BY event_time，结果把所有订单混在一起编号，完全失去单个订单内的时间线。正确做法是每个订单独立编号，确保状态变更序列可追溯。
实操建议：
- 必须用
PARTITION BY order_id切分订单粒度 -
ORDER BY event_time, event_id防止同一秒多事件时序不确定（event_id作为二级排序兜底） - 避免在
WHERE中提前过滤状态——会破坏完整轨迹，应在窗口计算后再筛选
如何用 LAG() 和 LEAD() 提取前/后状态做流转判断
分析“从已揽收→运输中→派送中”这类流转，本质是比对相邻行的状态值。LAG(status) 拿上一状态，LEAD(status) 拿下一状态，但要注意 NULL 边界问题：首条记录的 LAG 和末条的 LEAD 必然为 NULL，直接参与 CASE WHEN 判断会导致整行被跳过。
实操建议：
- 用
LAG(status) OVER (PARTITION BY order_id ORDER BY event_time)获取前序状态 - 用
COALESCE(LAG(status), 'INIT')替换 NULL，让初始状态可参与比较 - 流转条件写成
WHERE prev_status = 'picked_up' AND status = 'in_transit'，别用AND LAG(...) = ...这种嵌套写法，易出错且不可读
为什么 MAX(event_time) OVER (PARTITION BY order_id) 比子查询快得多
查每个订单最新状态时间，有人写 (SELECT MAX(event_time) FROM events e2 WHERE e2.order_id = e1.order_id)，数据量一过十万就明显变慢。窗口函数天然不触发关联，执行计划里是单次扫描，而相关子查询对主表每行都执行一次内层扫描。
实操建议：
- 所有“按订单聚合时间/状态/计数”的需求，优先用窗口函数替代子查询或 JOIN
- 注意
MAX(event_time) OVER (PARTITION BY order_id)返回的是每行都带最大时间，不是只一行结果——如需唯一行，再配合ROW_NUMBER() = 1过滤 - PostgreSQL 和 MySQL 8.0+ 支持完整窗口语法；旧版 MySQL 必须升级或改用变量模拟，但稳定性差
状态漏填或时间乱序时，ORDER BY event_time 会把分析搞崩
真实物流数据常有状态补录、时间戳回填、系统时钟误差等问题。如果直接按 event_time 排序，可能把“签收”排在“派送中”前面，导致 LAG() 算出错误流转。这不是窗口函数的问题，而是输入质量缺陷。
实操建议：
- 先用
COUNT(*) FILTER (WHERE event_time 统计时间倒序比例，超过 5% 就得清洗 - 对高风险字段（如
event_time、status）加CHECK CONSTRAINT或入库前校验逻辑 - 必要时引入业务规则兜底：例如“签收时间必须晚于创建时间 + 2 小时”，用
CASE WHEN临时修正异常值
窗口函数本身很稳，但物流轨迹分析的难点从来不在语法，而在状态定义是否一致、时间戳是否可信、补录逻辑是否透明——这些没法靠 OVER (PARTITION BY ...) 自动修复。
