ORDER BY 字段不唯一会导致 ROW_NUMBER() 分配不稳定，必须在 ORDER BY 末尾添加唯一列（如 id）兜底，并建立匹配的联合索引，同时用子查询/CTE 套一层实现正确分页。
ORDER BY 字段不唯一导致 ROW_NUMBER() 分配不稳定
只要 ORDER BY 里存在重复值（比如多个订单的 created_at 都是 '2025-08-27 12:00:00'），数据库就可能在不同执行中以不同物理顺序排列这些行，导致同一行被分配不同序号。这不是 bug，是 SQL 标准允许的未定义行为。
常见现象：第 1 页末尾出现 id=105，第 2 页开头又出现 id=105；刷新后某条记录“消失”或“跳页”。
- 必须在
ORDER BY末尾加一个唯一列兜底，例如ORDER BY created_at DESC, id DESC - 避免用
GETDATE()、NOW()这类运行时函数参与排序——每次执行值不同，直接破坏稳定性 - 时间字段精度不够（如只到秒）在高并发写入下极易冲突，哪怕建了索引也救不了
WHERE 条件写错位置，导致全表编号再过滤
很多人把 WHERE rn BETWEEN 21 AND 40 写在和 ROW_NUMBER() 同一层，但多数数据库（SQL Server、PostgreSQL）无法将这个条件下推到窗口计算前，结果是先对全表排序编号，再过滤——性能崩、内存爆、还容易因临时排序抖动引发重复。
- 务必用子查询或 CTE 套一层：
SELECT * FROM (SELECT *, ROW_NUMBER() OVER (ORDER BY created_at DESC, id DESC) AS rn FROM t) t2 WHERE t2.rn BETWEEN 21 AND 40 -
rn别名不能省——漏写就会报Invalid column name 'rn' - 别用
rn > 20 AND rn < 41替代BETWEEN，语义等价但部分优化器识别不到 TopN 提示
索引没对齐 OVER(ORDER BY ...)，强制走 Sort 算子
即使你写了 ORDER BY created_at DESC, id DESC，如果没建对应联合索引，数据库就得先全表扫描、再内存排序（Sort）、最后编号——I/O 和 tempdb 压力陡增，深分页时延迟飙升，且排序过程本身就不稳定。
- 索引必须严格匹配
OVER里的字段顺序和方向：CREATE INDEX IX_posts_time_id ON posts(created_at DESC, id DESC) - 如果常带
WHERE status = 'published'，把status放索引最左列：CREATE INDEX IX_posts_status_time_id ON posts(status, created_at DESC, id DESC) - 避免在排序字段上用表达式，比如
ORDER BY DATE(created_at)或ORDER BY UPPER(name)——索引直接失效
参数计算溢出或越界，让 rn 范围错位
用户传参 @page_index = 0 或 @page_size = 1000 时，(@page_index - 1) * @page_size 可能算出负数或超 INT 上限，导致 rn BETWEEN -1 AND 99 这种非法范围——有些数据库会静默修正，但行为不可靠。
- 服务端做参数校验：
@page_index > 0且@page_size在合理区间（如 1–1000） - 用
BIGINT类型承接偏移量计算，防止整型溢出 - 前端传参时避免手动拼接 SQL，一律走预编译参数
真正麻烦的不是写错语法，而是 ORDER BY 看似“够用”，实际在并发写入、索引缺失、参数边界这几个点上同时失守，问题才集中爆发。每个环节都得单独验证，不能靠感觉。
