PostgreSQL 16 分页查询：LIMIT/OFFSET 的正确打开方式
在 PostgreSQL 16 中，LIMIT 和 OFFSET 依然是最直观的分页语法，但背后有不少容易踩的坑。先说几个核心判断：不配合 ORDER BY，分页结果就是随机的；排序字段没有索引，性能会直线下降；而一旦翻到深页，这个方案基本就废了。
不加 ORDER BY？后果自负
这是一个常被忽视的陷阱。PostgreSQL 并不会保证无序查询的行序——哪怕表里有主键、哪怕数据刚刚写入。同一句 LIMIT 10 OFFSET 100 执行两次，很可能返回完全不同的 10 行。所以，ORDER BY 不是可选，而是必须。
ORDER BY id是最安全的做法，前提是id是主键或唯一索引。- 如果排序字段有重复值，比如多个用户在同一秒注册，需要追加一个唯一字段来消歧：
ORDER BY created_at, id。 - 尽量避免用函数来排序，比如
ORDER BY LOWER(name)，除非你专门建了函数索引，否则普通索引派不上用场。
LIMIT 和 OFFSET 的顺序，真别搞反
PostgreSQL 16 确实支持 OFFSET m LIMIT n 这种非标准语法，但这会带来维护上的困扰和不确定性。最佳实践是坚持标准顺序：LIMIT 20 OFFSET 100。另外要特别注意，LIMIT 20, 100 是 MySQL 的写法，在 PostgreSQL 里会直接报错，不会有任何妥协。
OFFSET 越大，性能越差——这不是夸张
当 OFFSET 达到十万级时，查询延迟会明显攀升。原因在于，PostgreSQL 必须真实地扫描并丢弃前 N 行数据，哪怕这些行根本不在最终结果里。即使 id 字段上有 B-tree 索引，OFFSET 1000000 依然会跳过一百万行，索引在此无能为力。
通过 EXPLAIN ANALYZE 可以清楚看到问题：Rows Removed by Filter 数值高得离谱，这就是典型的信号。对于小规模数据集（比如总行数在几万以内），LIMIT/OFFSET 仍然够用；但如果业务要求深翻页（比如第 500 页以后），就该考虑游标分页了——WHERE id > 123456 ORDER BY id LIMIT 20 是更好的替代方案。
MyBatis 和 ORM 中的页码计算陷阱
一个常见错误是混淆“第 N 页”和“跳过 N 条”的概念。有人会把页码从 0 开始算，或者直接用页码当作 OFFSET 参数。正确的做法很简单：
- 第 1 页（每页 20 条）：
OFFSET 0 - 第 2 页：
OFFSET 20，不是OFFSET 2 - 通用公式：
OFFSET = (page_number - 1) * page_size - MyBatis 中的正确写法：
LIMIT #{pageSize} OFFSET #{(pageNum - 1) * pageSize} - 别忘了校验
pageNum≥ 1，否则OFFSET -20会直接报错
归根结底，写对语法不是最难的部分，真正关键的是判断什么时候该放弃 OFFSET。只要业务允许“上一页/下一页”而非“跳转到第 N 页”，游标分页就应该是默认选项。而 LIMIT/OFFSET 更适合作为开发初期的快速验证手段，不是生产环境的长期方案。
