SQL窗口函数分页为什么会出现重复数据-SQL-PHP中文网

order by 字段不唯一会导致 row_number() 分配不稳定，必须在 order by 末尾添加唯一列（如 id）兜底，并建立匹配的联合索引，同时用子查询/cte 套一层实现正确分页。

sql窗口函数分页为什么会出现重复数据

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 替代 <code>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 这种非法范围——有些数据库会静默修正，但行为不可靠。