如何在PostgreSQL中借助FETCH FIRST语法实现标准SQL分页？

必须用ORDER BY + OFFSET + FETCH NEXT组合实现稳定分页，无ORDER BY时结果不可预测；ORDER BY字段需建索引，重复值时应追加唯一列保序；大OFFSET性能差，深分页应改用键集分页。

PostgreSQL 从 8.4 开始支持 OFFSET/FETCH，但真正稳定可用、语义清晰的分页必须用 ORDER BY + OFFSET + FETCH NEXT 组合，不能只靠 LIMIT/OFFSET 应付深分页。

FETCH NEXT 必须搭配 ORDER BY 才有效

没有 ORDER BY 的 FETCH NEXT 查询结果不可预测，PostgreSQL 不会报错，但翻页时数据会乱序或重复。这是最容易被忽略的前提条件。

• ORDER BY 列必须有索引，否则每次分页都触发全表扫描
• 如果排序字段存在大量重复值（比如 status），建议追加一个唯一列（如 id）作为第二排序项：ORDER BY status DESC, id DESC
• 避免在 ORDER BY 中使用函数或表达式（如 ORDER BY UPPER(name)），否则索引失效

OFFSET 越大，性能越差——这不是 PostgreSQL 特有，而是 SQL 标准执行模型决定的

OFFSET 100000 实际上会让 PostgreSQL 扫描并丢弃前 100000 行，哪怕你只想要 20 行。实测 1 亿行表中，OFFSET 1000000 耗时超过 2 秒，且 CPU 和 I/O 压力陡增。

• 不要把 OFFSET 当成“页码 × 每页条数”直接代入生产查询
• 对高并发、深分页场景（如后台管理页 > 500 页），应改用键集分页（keyset pagination），例如记录上一页最后的 created_at 和 id，下一页用 WHERE (created_at, id)
• FETCH FIRST 20 ROWS ONLY 和 FETCH NEXT 20 ROWS ONLY 功能完全等价，选哪个纯看团队习惯

WITH TIES 解决“并列排序值导致漏行/重叠”问题

当多行共享同一个排序键（如相同 score），FETCH FIRST 5 ROWS ONLY 可能截断并列项，造成用户看到第 1 页有 Alice/Bob，第 2 页又出现 Bob —— 这不是 bug，是设计如此。

• 用 FETCH FIRST 5 ROWS WITH TIES 可强制包含所有并列行，返回行数 ≥ 5
• 它依赖 ORDER BY 的完整表达式，例如 ORDER BY score DESC, id ASC 中的 id 仅用于打破并列，不参与 WITH TIES 判定
• WITH TIES 在 PostgreSQL 13+ 完整支持，旧版本（如 12 或更早）会报错或忽略该关键字

真正难的不是写对语法，而是判断什么时候该放弃 OFFSET、什么时候必须加 WITH TIES、以及如何让 ORDER BY 同时满足业务语义和索引效率——这些细节一旦疏忽，线上分页接口就容易在流量高峰突然变慢或返回错乱数据。