必须加ORDER BY，否则OFFSET无序计算导致数据遗漏或重复；根本原因是无排序时行顺序不确定，OFFSET偏移基准漂移。
OFFSET 为什么总返回空结果或跳过数据
直接写 SELECT * FROM users OFFSET 10 LIMIT 5 看似没问题，但实际常漏掉第 11 条——根本原因是没加 ORDER BY。SQL 标准不保证无序查询的行顺序，每次执行 OFFSET 可能基于不同物理顺序计算偏移，导致重复或遗漏。
必须搭配确定性排序：
-
ORDER BY id最稳妥（主键唯一、索引支持好） - 避免用
ORDER BY created_at（时间可能重复，排序不稳定） - 若必须按非唯一字段排序，补一个主键去重：
ORDER BY name, id
OFFSET 越大性能越差的真实原因
OFFSET 10000 LIMIT 20 不是“跳过前 10000 行再取 20 行”，而是数据库先扫描并丢弃前 10000 行，再取后续 20 行。全表扫描成本随偏移量线性增长，尤其在千万级表上会明显变慢。
替代思路不是优化 OFFSET，而是绕开它：
- 用游标分页（
WHERE id > 12345 ORDER BY id LIMIT 20），适合无限滚动 - 前端缓存上次请求的最小/最大排序值，下次传入作为边界条件
- 对实时性要求低的场景，可预生成分页视图或物化中间结果
MySQL 和 PostgreSQL 对 OFFSET 的处理差异
语法一致，但底层行为有细节差别：
- MySQL 8.0+ 支持
LIMIT offset, row_count（如LIMIT 10, 5），等价于OFFSET 10 LIMIT 5；旧版本只认前者 - PostgreSQL 允许
OFFSET不带LIMIT，但实际业务中几乎不用——没限制的偏移毫无意义 - 两者都要求
OFFSET必须是非负整数，传负数会报错：ERROR: OFFSET must not be negative
如何安全地实现“上一页 / 下一页”逻辑
用户点击“下一页”时，不能简单把当前 OFFSET 加 LIMIT 值，因为中间数据可能被删或新增，导致页码错位。更可靠的做法是：
- 返回当前页最后一条记录的排序字段值（如
id = 105），下一页请求带上WHERE id > 105 ORDER BY id LIMIT 20 - “上一页”则需反向查：取当前页第一条的
id，然后WHERE id ，再反转结果 - 禁止暴露
OFFSET数值给前端（比如 URL 里写?page=500），容易被恶意刷出高偏移查询
OFFSET 本身没有错，但它是个“面向过程”的偏移概念，而分页本质是“面向状态”的数据切片——真正难的从来不是怎么写那条 SQL，而是怎么让每一页的边界在数据动态变化时依然可重现。
