ORDER BY字段重复会导致ROW_NUMBER()序号不稳定，因数据库对相同值行不保证物理顺序；必须添加唯一兜底字段（如主键）、显式处理NULL、下推WHERE条件并建立合适索引，才能确保分页结果可重现。
ORDER BY字段重复时，ROW_NUMBER()分配序号不一致
数据库对相同排序值的行不保证物理顺序，ROW_NUMBER()只是按当前执行时的“临时顺序”编号。比如两行都满足 created_at = '2026-11-01 10:00:00'，某次查询可能是第1行先排、另一次变成第2行先排——rn 值跟着变，翻页就漏或重复。
WHERE条件写在外层会放大不稳定效应
如果把过滤逻辑放在外层，比如：
SELECT * FROM ( SELECT *, ROW_NUMBER() OVER (ORDER BY created_at DESC) AS rn FROM logs ) t WHERE t.rn BETWEEN 101 AND 120
——数据库必须先给全表编号，而编号本身已不稳定；哪怕只取20条，也得在混乱序号里硬截，结果不可重现。正确做法是把 WHERE status = 'done' 这类条件下推到内层子查询，缩小参与排序的数据集，再编号。
MySQL/PostgreSQL 对 NULL 的默认排序行为不同
同一句 ORDER BY event_time DESC，在 PostgreSQL 中 NULL 排最前，在 MySQL 中排最后。如果 event_time 允许为空，且没显式处理，两次查询的排序起点就不同，ROW_NUMBER() 自然跟着漂移。
- PostgreSQL 应补
NULLS LAST（或NULLS FIRST，按需） - MySQL 可用
IFNULL(event_time, '1970-01-01')统一兜底 - SQL Server 默认把
NULL当最小值，若业务要最大值语义，得用CASE WHEN event_time IS NULL THEN '9999-12-31' ELSE event_time END
唯一兜底字段选错也会失效
以为加个 id 就万事大吉，但若实际主键是 log_id，而你写了 ORDER BY created_at DESC, user_id DESC，而 user_id 并非唯一，仍可能重复。关键不是“有没有第二列”，而是“第二列能否在第一列相同时彻底打破平局”。
- 优先用主键或带唯一约束的列（如
log_id、uuid） - 避免用业务字段如
username（可能重名）、dept_name（可能重复） - 若只有时间字段，且精度不足（如只有秒级），可考虑补上更高精度字段，或用
ROW_NUMBER() OVER (ORDER BY created_at DESC, log_id DESC)
真正让 ROW_NUMBER() 分页稳定下来的，从来不是函数本身，而是你是否控制住了排序的确定性——从索引、NULL 处理、兜底字段选择，到谓词下推，每一步松动，都会在翻页时露出破绽。
