首页 > 数据库 >PostgreSQL如何用FETCH FIRST语法实现标准SQL分页？

PostgreSQL如何用FETCH FIRST语法实现标准SQL分页？

来源：互联网 2026-07-10 10:47:01

说到PostgreSQL分页，很多开发者第一反应就是LIMIT/OFFSET。但如果你要处理的是深分页、高并发场景，最好回归标准SQL的写法：ORDER BY + OFFSET + FETCH NEXT。PostgreSQL从8.4开始就支持OFFSET/FETCH，但真正稳定可用、语义清晰的分页，

说到PostgreSQL分页，很多开发者第一反应就是LIMIT/OFFSET。但如果你要处理的是深分页、高并发场景，最好回归标准SQL的写法：ORDER BY + OFFSET + FETCH NEXT。PostgreSQL从8.4开始就支持OFFSET/FETCH，但真正稳定可用、语义清晰的分页，必须用这个组合，不能只靠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) < ($1, $2) 条件
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 同时满足业务语义和索引效率——这些细节一旦疏忽，线上分页接口就容易在流量高峰突然变慢或返回错乱数据。

侠游戏发布此文仅为了传递信息，不代表侠游戏网站认同其观点或证实其描述