说到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 同时满足业务语义和索引效率——这些细节一旦疏忽，线上分页接口就容易在流量高峰突然变慢或返回错乱数据。
