row_number()最合适，因其为每条物流记录分配唯一序号，确保“第1步→第2步→第3步”的严格时序；rank()和dense_rank()会使相同时间戳记录共享序号，导致进度计算错误。
窗口函数怎么选：ROW_NUMBER()、RANK() 还是 DENSE_RANK()？
实时物流进度不是简单排序，而是按时间戳对每个订单的物流事件做有序标记。用 ROW_NUMBER() 最合适——它强制给每条物流记录分配唯一序号，哪怕同一时间有多条记录（比如系统批量写入），也能保证“第1步→第2步→第3步”的严格时序。用 RANK() 或 DENSE_RANK() 会导致相同时间戳的记录共享同一个序号，后续计算“当前第几步/共几步”就会出错。
- 必须按
order_id分组，再按event_time升序排序 - 避免用
created_at替代event_time：后者是物流系统真实上报时间，前者可能是数据库插入时间，有延迟 - 如果事件时间精度到秒但存在并发写入，建议在排序中追加
event_id作为次要排序键，防止窗口函数结果不稳定
怎么算“当前进度百分比”：用 COUNT(*) OVER 还是 MAX(序号)？
别用 COUNT(*) OVER (PARTITION BY order_id) 算总步数——它统计的是当前行所在窗口内的行数，而窗口默认是 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，导致每行的分母都在变小。正确做法是先用子查询或 CTE 给每个订单算出总事件数，再关联回来。更简洁的是直接用 MAX(step_num) OVER (PARTITION BY order_id)，前提是 step_num 是用 ROW_NUMBER() 生成的连续整数。
- 示例表达式：
ROUND(100.0 * step_num / MAX(step_num) OVER (PARTITION BY order_id), 1) - 注意除零：某些订单可能只有1条物流记录（比如刚揽收），此时
MAX(step_num)就是1，没问题；但若订单无物流记录（LEFT JOIN场景），需提前COALESCE(..., 0) - 百分比值建议保留1位小数，用
ROUND(..., 1)，避免浮点误差显示成 99.9999999
如何让“最新状态”和“进度”同步更新？
物流事件是流式写入的，不能依赖定时任务刷新视图。必须用实时可查的 SQL 表达式，且避免 N+1 查询。核心技巧是把窗口函数嵌套进条件聚合：用 MAX(CASE WHEN step_num = max_step THEN event_type END) 提取最新事件类型，再与进度字段同级计算。
- 不要写两个独立的窗口函数分别算
max_step和latest_event，会导致重复扫描；应先用 CTE 算出step_num和max_step，再在外层聚合 - 如果数据库不支持 CTE（如旧版 MySQL），可用内联视图，但需确保外层
GROUP BY order_id不丢失明细行 - 注意 NULL 处理：
event_type为空时，CASE返回 NULL，MAX()会忽略它——这反而是优点，能自动跳过脏数据
MySQL 8.0 和 PostgreSQL 的关键差异点
PostgreSQL 对窗口函数支持更宽松，允许在 WHERE 子句里直接引用窗口函数别名；MySQL 8.0 不行，所有窗口计算必须放在 SELECT 或子查询里，且 ORDER BY 在窗口定义中必须显式声明，不能依赖外部排序。
- MySQL 报错
Window 'w' is not allowed here，通常是因为在HAVING或WHERE中用了窗口别名——得改用子查询包裹 - PostgreSQL 可以用
WINDOW w AS (PARTITION BY order_id ORDER BY event_time)定义命名窗口，复用更干净；MySQL 必须每处重复写完整定义 - 两者都支持
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，但 PostgreSQL 默认就是这个框架，MySQL 需显式写出，否则默认是RANGE模式，可能因时间精度问题漏行
实际跑起来你会发现，真正卡住的往往不是语法，而是物流事件时间乱序、重复上报、或部分订单缺失关键节点（比如跳过“已发货”直接到“派件中”）。这些得靠上游清洗，SQL 层只能尽力容错——比如用 LAG(event_type) 检查状态跳跃，但别指望它自动补全缺失环节。
