OFFSET越大查询越慢，因PostgreSQL需真实扫描并丢弃前OFFSET行；应改用游标分页（如WHERE id>12345 ORDER BY id LIMIT 20），配合唯一排序字段和索引以保证性能与稳定性。
为什么 OFFSET 越大，查询越慢
因为 PostgreSQL 必须先扫描并跳过前 OFFSET 行，才能返回后续结果。比如 OFFSET 1000000，数据库就得真实读取并丢弃前一百万行——哪怕只想要 20 条。这和索引是否覆盖无关，是执行计划层面的硬开销。
常见错误现象：EXPLAIN ANALYZE 显示 Seq Scan 或 Index Scan 的 Rows Removed by Filter 高得离谱；响应时间随 OFFSET 线性增长。
- 适用场景：仅限小数据集（
OFFSET - 若主键连续、无删改，可考虑用
WHERE id > last_seen_id LIMIT 20替代（游标分页） - 加
ORDER BY id是必须的，否则OFFSET结果不可预测
LIMIT 和 OFFSET 的参数顺序不能颠倒
LIMIT 必须在 OFFSET 前面，语序固定为 LIMIT n OFFSET m。写成 OFFSET m LIMIT n 在某些旧版本（如 9.4 之前）会报错，新版本虽兼容但属非标准写法，不建议依赖。
示例正确写法：
SELECT * FROM users ORDER BY id LIMIT 20 OFFSET 100;
-
LIMIT 20 OFFSET 100✅ 标准且稳定 -
OFFSET 100 LIMIT 20⚠️ 语法上可能通过，但易引发团队理解偏差 - 省略
OFFSET时，LIMIT 20等价于LIMIT 20 OFFSET 0
ORDER BY 缺失会导致分页结果混乱
没有 ORDER BY，PostgreSQL 不保证行的返回顺序，同一查询多次执行可能拿到不同“第 21–40 行”，OFFSET 就失去意义。
更隐蔽的问题：即使表有主键，也不代表查询自动按主键排序。显式写 ORDER BY id 才可靠。
- 如果排序字段有重复值（如多个用户同一天注册），需补一个唯一字段消歧，例如
ORDER BY created_at, id - 避免在
ORDER BY中使用函数或表达式（如ORDER BY LOWER(name)），除非该表达式有对应函数索引，否则无法高效走索引 - 复合排序字段顺序要和索引定义一致，否则索引可能失效
用游标分页替代 OFFSET 的实际写法
当需要稳定、高性能的深分页时，应放弃 OFFSET，改用基于上一页最后一条记录的“游标”方式。核心是把 OFFSET 的“跳过 N 行”逻辑，转为“从某条记录之后取 N 行”。
假设上一页最后一条是 id = 12345，下一页查询：
SELECT * FROM users WHERE id > 12345 ORDER BY id LIMIT 20;
- 必须确保
WHERE条件和ORDER BY字段一致（如都用id），且该字段有索引 - 前端需保存上一页末尾的
id（或其他唯一排序字段值），不能只记页码 - 不支持直接跳转到第 100 页，但支持无限向下翻页，且性能恒定
游标分页的边界情况比 LIMIT/OFFSET 多——比如删除导致“断号”、并发插入影响可见性。这些细节不处理好，反而比 OFFSET 更难调试。
