ROW_NUMBER()必须配合PARTITION BY和ORDER BY才能标记订单生命周期序号；单独使用仅生成全表流水号，无法实现“每订单独立计数”，且ORDER BY需用带业务语义的时间字段（如status_changed_at）并辅以id防重复，确保序号稳定连续。
ROW_NUMBER() 必须配合 PARTITION BY 和 ORDER BY 才能标记生命周期序号
单独写 ROW_NUMBER() 不会按订单生命周期分组编号，它默认对全表排序编号。要给每个订单的每条状态记录打上“第1次下单、第2次修改、第3次发货”这类序号，必须明确告诉数据库：按订单分组（PARTITION BY order_id），再按时间先后排序（ORDER BY created_at）。漏掉 PARTITION BY 就变成全局流水号，完全失去“每个订单独立计数”的意义。
ORDER BY 字段必须能反映真实生命周期顺序
常见错误是用 id 或 updated_at 排序，但订单状态变更可能批量更新导致 updated_at 相同，或软删除记录干扰 id 顺序。优先选带业务语义的时间字段，比如：status_changed_at、event_time；若没有，至少用 created_at 并确认其写入逻辑可靠。如果存在同一秒多条记录，建议追加 id 作为二级排序：ORDER BY created_at, id，避免窗口函数结果不稳定。
注意 NULL 值和重复状态对序号连续性的影响
ROW_NUMBER() 严格按排序输出 1、2、3…，不跳过也不合并。这意味着：
- 哪怕两条记录状态相同（如两次“已支付”），也会被编为 1 和 2
- 若某订单缺失“已取消”前的中间状态，序号依然连续，不会补空位
-
NULL值在ORDER BY中默认排最前（PostgreSQL/SQL Server）或最后（MySQL 8.0+），可能把脏数据顶到序号 1，建议提前用WHERE status IS NOT NULL过滤
如果业务上需要“去重后编号”，得先用 DISTINCT ON（PostgreSQL）或子查询去重，再套 ROW_NUMBER()。
在 UPDATE 或物化视图中复用生命周期序号要小心性能
直接在 UPDATE 语句里嵌套 ROW_NUMBER() 窗口函数多数数据库不支持（MySQL 5.7 报错，SQL Server 要用 CTE）。可行做法是：
- 用 CTE 先算出序号，再 JOIN 回原表更新：
WITH ranked AS (SELECT id, ROW_NUMBER() OVER (PARTITION BY order_id ORDER BY created_at) AS seq FROM order_events) - 避免在高频更新的表上实时计算——把序号存为冗余字段，由应用层或触发器维护
- 如果只是查报表，且数据量大（>100 万行），确保
(order_id, created_at)有联合索引，否则PARTITION BY + ORDER BY会全表扫描
真正麻烦的是跨库同步场景：Oracle 的 ROW_NUMBER() 行为和 MySQL 8.0 虽然一致，但时区处理、微秒精度差异可能导致同一份数据在不同库生成不同序号——这种细节往往上线后才暴露。
