OFFSET分页易错因未绑定ORDER BY或排序字段不唯一，导致数据重复、遗漏；大偏移量性能差，应改用游标分页（WHERE+主键）。
OFFSET在SQL分页中为什么经常查错数据？
OFFSET不是“跳过前N条”，而是“跳过排序后结果集的前N条”——这个前提被很多人忽略，导致分页时数据重复、遗漏或顺序错乱。它必须和ORDER BY严格绑定，否则数据库可能按任意物理顺序返回行，OFFSET行为不可预测。
常见错误现象：SELECT * FROM users OFFSET 20 LIMIT 10 没有ORDER BY，两次执行可能返回不同用户；用id排序但id不唯一（比如软删除场景），OFFSET 20 可能跳过一批相同id的记录。
- 必须显式写
ORDER BY，且排序字段要具备确定性（推荐组合主键或带唯一约束的字段） - 避免用
ORDER BY created_at单独排序：高并发下时间戳可能重复，导致OFFSET偏移量计算失准 - 如果业务允许，优先考虑游标分页（基于上一页最后一条的
id或created_at + id），而非OFFSET
MySQL/PostgreSQL里OFFSET的性能陷阱
OFFSET M LIMIT N 实际要扫描前M+N行数据，M越大越慢。PostgreSQL在大OFFSET时会放弃索引，改用顺序扫描；MySQL 5.7之前甚至无法用索引跳过OFFSET部分。
实测对比（千万级表）：SELECT * FROM orders ORDER BY id LIMIT 10 OFFSET 100 耗时2ms；OFFSET 100000 耗时320ms；OFFSET 1000000 耗时超2s且CPU飙升。
- MySQL 8.0+ 支持
LIMIT … OFFSET的优化，但仅当ORDER BY字段有覆盖索引时才生效 - PostgreSQL建议对分页字段建复合索引，例如
CREATE INDEX idx_orders_id ON orders(id)（升序默认） - 真实业务中，超过
OFFSET 10000应强制切换为游标分页，前端禁止输入超大页码
如何用WHERE + 主键实现无OFFSET的稳定分页？
本质是把“第N页”转换为“大于上一页最后一条主键值的前N条”。它绕过OFFSET的扫描开销，且天然避免重复/遗漏。
示例（从第2页开始，每页10条）：
SELECT * FROM users WHERE id > 105 ORDER BY id LIMIT 10;
这里105是第1页最后一条记录的id。关键点在于：必须确保ORDER BY和WHERE条件指向同一字段，且该字段单调递增、无空值、无重复。
- 若排序依据是
created_at DESC, id DESC，则WHERE需写成WHERE (created_at, id) （注意方向一致） - 不能用
WHERE created_at 这种拆开写法，会导致漏掉同时间戳的不同<code>id - 首次查询仍需全排序获取首屏，但后续所有翻页都极快
ORM框架里OFFSET容易被自动注入的坑
像Django ORM的.offset()、SQLAlchemy的offset()方法看似安全，但一旦链式调用中混入.distinct()或.group_by()，生成的SQL可能让OFFSET作用在子查询结果上，而子查询未排序——这时OFFSET就失效了。
错误示例（Django）：User.objects.values('city').distinct().order_by('city').offset(10).limit(5)，生成SQL中OFFSET在DISTINCT之后，但DISTINCT本身不保证顺序。
- 检查ORM生成的SQL，确认
ORDER BY出现在最外层，且覆盖所有去重字段 - 避免在分页查询中使用
.annotate()后直接.offset()，聚合可能导致排序字段丢失 - MyBatis里
<pageHelper>插件默认加OFFSET，但若SQL含UNION，需手动关闭分页或改用游标
OFFSET本身逻辑简单，但它的可靠性完全依赖排序的确定性和执行计划的稳定性。线上环境一旦出现分页错乱，第一反应不该是调大OFFSET，而是检查ORDER BY是否真正唯一、索引是否生效、ORM是否悄悄改写了查询结构。
