ROW_NUMBER()必须配合ORDER BY才能按时间排序，否则序号不确定；时间戳重复时需加主键等次级排序保证稳定；分组编号须用PARTITION BY；更新原表需通过CTE或JOIN中转。
ROW_NUMBER() 必须配合 ORDER BY 才能按时间排序
不写 ORDER BY 的 ROW_NUMBER() 会返回不确定序号，哪怕表里时间字段有索引或物理存储有序——SQL 标准不保证任何默认顺序。日志数据尤其容易因批量插入、分区合并导致物理顺序与业务时间错位。
正确写法是显式按时间字段升序（通常用 log_time 或 created_at）：
SELECT *,
ROW_NUMBER() OVER (ORDER BY log_time ASC) AS rn
FROM logs;
注意：ASC 可省略，但建议写明，避免和后续可能加的 PARTITION BY 混淆；如果日志含毫秒级时间且存在并发写入，需确认该字段是否真正唯一，否则相同时间戳会导致排序不稳定（见下一条）。
时间戳重复时 ROW_NUMBER 仍会强制编号，但结果不可预测
当多条日志的 log_time 完全相同时，ROW_NUMBER() 会任意分配序号（取决于查询优化器选择的扫描路径或底层存储顺序），这不是 bug，而是标准行为。线上日志系统常因应用层未控制精度、NTP 同步延迟或数据库自动补零导致大量重复时间戳。
稳妥做法是追加一个确定性次级排序条件：
- 优先用主键（如
id）：它通常自增、唯一、有索引，能稳定打破平局 - 若无主键，可用
ctid（PostgreSQL）或%%physloc%%（SQL Server）等物理位置标识，但跨版本/备份后失效，仅限临时排查 - 避免用
NEWID()或随机值，会破坏重跑一致性
示例：
ROW_NUMBER() OVER (ORDER BY log_time ASC, id ASC) AS rn
按业务维度分组重编序号要用 PARTITION BY
比如要对每个用户各自的日志单独从 1 开始编号，不能只靠全局排序。此时必须用 PARTITION BY 划分窗口：
SELECT user_id, log_time, message,
ROW_NUMBER() OVER (
PARTITION BY user_id
ORDER BY log_time ASC, id ASC
) AS user_log_seq
FROM logs;
关键点：
-
PARTITION BY在ORDER BY之前执行，先分组再组内排序编号 - 分区字段（如
user_id）若含 NULL，所有 NULL 值会被归为同一组，需提前WHERE user_id IS NOT NULL过滤 - 大表慎用高基数分区字段（如每条日志都不同
request_id），可能触发大量小窗口计算，拖慢性能
重编号结果不能直接 UPDATE，得用 CTE 或子查询中转
想把新序号存回原表？别试图直接 UPDATE ... SET rn = ROW_NUMBER()...——多数数据库不支持在 UPDATE 的 SET 子句里用窗口函数。正确路径是先生成编号，再关联更新：
PostgreSQL / SQL Server / Oracle 写法（CTE）：
WITH numbered AS (
SELECT id,
ROW_NUMBER() OVER (ORDER BY log_time, id) AS new_rn
FROM logs
)
UPDATE logs
SET seq_no = numbered.new_rn
FROM numbered
WHERE logs.id = numbered.id;
MySQL 8.0+ 类似，但需注意：MySQL 不支持 UPDATE ... FROM 语法，得改用 JOIN：
UPDATE logs l
JOIN (
SELECT id,
ROW_NUMBER() OVER (ORDER BY log_time, id) AS new_rn
FROM logs
) nr ON l.id = nr.id
SET l.seq_no = nr.new_rn;
真正容易被忽略的是：如果日志表正在被持续写入，上述更新过程可能漏掉新插入的行，或与并发写入产生主键冲突。生产环境务必加锁或选在低峰期执行。
