必须用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 压力陡增。
PostgreSQL 18.4 ubuntu
下载
PostgreSQL 18.4 官方 Ubuntu 安装包现已发布，这是目前最新的稳定版本。推荐通过官方 APT 仓库安装：先执行 sudo apt update 更新索引，再运行 sudo apt install postgresql-18 即可完成部署。新版本引入了异步 I/O 子系统，在顺序扫描与 VACUUM 场景下性能提升显著，同时支持 UUID v7 原生生成函数与虚拟生成列。
- 不要把
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 同时满足业务语义和索引效率——这些细节一旦疏忽，线上分页接口就容易在流量高峰突然变慢或返回错乱数据。
