row_number()能解决数据变更导致的翻页错位问题，但无法绕过全量排序开销；它适合中小数据集或强一致性要求场景，不是大偏移分页的性能救星。
直接说结论：ROW_NUMBER() 能解决数据变更导致的翻页错位问题，但无法绕过全量排序开销；它适合中小数据集或强一致性要求场景，不是大偏移分页的性能救星。
为什么 ROW_NUMBER() 分页不提速大 OFFSET 查询
很多人误以为用窗口函数就能“替代” LIMIT/OFFSET 来提升深分页性能。实际并非如此：ROW_NUMBER() 必须先对全部符合条件的行执行 ORDER BY 排序，再编号，最后过滤。这意味着：当你要取第 10001–10020 行时，数据库仍得把前 10020 行全排一遍——和 OFFSET 10000 的扫描量几乎一致。
常见错误现象：
- 执行
EXPLAIN ANALYZE后看到WindowAgg节点耗时占 95% 以上 - 加了索引但执行计划里仍是
Sort而非Index Scan Backward - 数据量刚过百万，查询就从毫秒级跳到秒级
根本原因在于：窗口函数不跳过数据，只编号；而性能瓶颈在排序本身，不在“跳过”逻辑。
ROW_NUMBER() 真正该用在哪种分页场景
它核心价值不是“快”，而是“稳”——尤其在数据高频写入、排序字段存在大量重复值的后台管理类接口中。
典型适用条件：
- 排序字段（如
status、updated_at）有大量相同值，仅靠ORDER BY status DESC无法保证结果稳定 - 业务要求“第 N 页必须固定”，不能因并发插入导致某条记录在第 2 页出现两次或直接消失
- 页码可控（比如只允许翻到前 200 页），且单页数据量不大（≤ 50 条）
务必补上唯一决胜列，例如：
ROW_NUMBER() OVER (ORDER BY status DESC, updated_at DESC, id DESC)
漏掉 id 这类唯一列，PostgreSQL 可能每次返回不同顺序，rn BETWEEN 41 AND 60 就会漏数或重复。
索引怎么建，ROW_NUMBER() 才不拖垮查询
窗口函数本身不走索引，但 OVER () 里的 ORDER BY 字段如果能被索引覆盖，就能避免排序操作。关键不是建单列索引，而是复合索引 + INCLUDE。
正确做法：
- 按
OVER中的排序顺序建联合索引，例如ORDER BY status, updated_at DESC, id→ 建索引CREATE INDEX idx_tasks_sort ON tasks(status, updated_at DESC, id) - 如果查询还选了其他字段（如
title、content），用INCLUDE把它们带上：INCLUDE (title, content)，实现索引覆盖，避免回表 - 避免在
WHERE子句里加破坏索引使用的条件，比如WHERE status != 'draft'可能让索引失效，改用status IN ('active', 'pending')
错误示例：CREATE INDEX idx_bad ON tasks(updated_at DESC) —— 单列索引无法支撑多字段排序，照样触发 Sort 节点。
比 ROW_NUMBER() 更适合大数据量分页的替代方案
如果你的表有千万级以上数据，且用户真会翻到第 5000 页，别硬扛窗口函数。优先考虑键集分页（游标分页）：
- 首次查第一页：
SELECT id, status, updated_at FROM tasks ORDER BY id DESC LIMIT 20，记下最小id（比如 9981） - 下一页查：
SELECT id, status, updated_at FROM tasks WHERE id - 确保
id是主键或有高效索引，且严格单调递增（不能是 UUID 或随机生成值）
这种写法不依赖行号，每次只扫一页数据量，OFFSET 多大都不影响速度。真正的性能分水岭不在语法，而在你是否愿意放弃“跳转到任意页”的交互设计。
