ROW_NUMBER()不能直接用于多级中转订单路径排序，因其仅按字段机械编号，无法识别“上一站→下一站”的拓扑关系；需借助递归CTE依实际流转时序重建路径并编号。
为什么 ROW_NUMBER() 不能直接用于多级中转订单的路径排序
因为 ROW_NUMBER() 只按指定字段排序后硬性编号，无法感知“上一站→下一站”的拓扑关系。比如订单从 A→B→C，但数据库里三条记录时间戳接近、站点字段无序，单纯按 created_at 或 station_name 排会得到 B→A→C 这种错序。
真正需要的是：从起点出发，顺着物流流转链条逐跳编号。这要求先识别出每个订单的首站（入仓点）和末站（签收点），再基于实际流转方向重建路径。
- 必须有明确的“前序站点”字段（如
prev_station）或能推导出流向的字段（如scan_time+scan_type） - 若只有离散扫描记录，需先用自连接或递归 CTE 找出逻辑先后关系，
ROW_NUMBER()才有可靠排序依据 - MySQL 8.0+、PostgreSQL、SQL Server 2017+ 支持递归 CTE；旧版 MySQL 只能靠应用层拼接或临时表模拟
用递归 CTE 构建物流路径并编号（PostgreSQL / SQL Server）
假设表 logistics_scans 包含 order_id、station_code、scan_time、scan_type（如 'INBOUND', 'TRANSIT', 'OUTBOUND', 'DELIVERED'），目标是为每个订单生成 path_step（1=首站，2=中转，3=末站）。
关键不是直接排序，而是把每条扫描记录当作图的一个节点，用递归找出从入仓到签收的唯一链路：
LAG()
- 对每个
order_id按path_step排序后，用LAG(station_code) OVER (PARTITION BY order_id ORDER BY path_step)获取上一站 - 若某行的
prev_station字段与LAG(station_code)不一致，说明原始数据存在录入矛盾 - 更实用的是用
LEAD(path_step) OVER (...) - path_step查看步长，结果不等于 1 就是漏站（如 2→4 表示缺失第 3 步）
这种校验必须在重排后立刻做，否则下游按错误序号做时效分析会系统性偏差。
MySQL 5.7 无递归 CTE 时的替代方案
只能放弃纯 SQL 路径重建，改用分步策略：先用应用代码（Python/Java）按 order_id + scan_time 分组排序，生成临时路径表；再用 JOIN 回原表赋予 path_step。强行在 MySQL 5.7 里用自连接模拟递归，性能极差且易超内存。
如果必须 SQL 内解决，至少做到：
- 加复合索引：
INDEX(order_id, scan_time, scan_type)，加速分组排序 - 用变量模拟序号：
@step := IF(@prev = order_id, @step + 1, 1)，但注意 MySQL 8.0 之前变量执行顺序不保证，需配合ORDER BY强制 - 永远不要依赖
GROUP_CONCAT()拼路径再拆分——长度限制、编码问题、无法反查原始记录
路径重排的本质是图遍历，不是排序。窗口函数只是编号工具，前提是你已经构造出正确的节点序列。没拓扑信息就硬套 ROW_NUMBER()，只会把混乱固化成“看起来有序”的错误结果。
