如何利用ROW_NUMBER和游标在PostgreSQL中高效实现分页查询？

本文共计978个文字，预计阅读时间需要4分钟。

由于 PostgreSQL 必须从排序结果的开头逐行扫描，才能跳过 `OFFSET` 指定的全部行，才能获取到目标数据。当 `OFFSET` 是 100 万时，数据库实际上读取了 100 万 + `LIMIT` 行，时间复杂度是 O(OFFSET + LIMIT)。如果已有索引，则无需使用跳过前 N+ 行的能力，其效率仍然是一遍扫描。

ROW_NUMBER() 真的比 OFFSET 快吗

不一定快，甚至可能更慢——尤其在没加合适索引、或返回字段多、或排序列不唯一时。ROW_NUMBER() 需要先对全表（或满足 WHERE 条件的部分）完成完整排序并编号，再过滤，本质仍是“全量计算 + 截断”。

• 只适合中小数据集（比如
• 必须确保 ORDER BY 列有索引，否则性能雪崩；推荐组合索引，例如 CREATE INDEX idx_orders_created_at_id ON orders(created_at DESC, id DESC)
• 避免在 OVER() 里用函数或表达式排序，比如 ORDER BY lower(name)，这会让索引失效
• 如果排序列存在重复值，ROW_NUMBER() 生成的序号是不确定的（除非补上唯一列保序），可能导致同一页数据重复或遗漏

游标分页（Keyset Pagination）怎么写才有效

这是真正能解决深分页性能问题的方法：它不依赖“第几页”，而是记住上一页最后一条记录的排序键值，用 WHERE 直接定位下一页起点。查询复杂度稳定在 O(log N)，和页码无关。