PostgreSQL 16中LIMIT和OFFSET基础分页查询

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 更适合作为开发初期的快速验证手段，不是生产环境的长期方案。