OFFSET越大查询越慢，因MySQL需扫描并丢弃前offset行，导致I/O和CPU开销激增；超100万时还可能引发内存不足、数据不一致等问题。
为什么 OFFSET 越大查询越慢
MySQL 在执行 LIMIT offset, size 时，即使只返回 size 行，也必须先跳过前 offset 行——这意味着它得扫描并丢弃那么多行。如果 OFFSET 是 100 万，MySQL 就得读取并跳过 100 万行（哪怕这些行早就在内存里），I/O 和 CPU 开销都会上升，尤其在没有合适索引或数据量大的表上，响应可能从毫秒级变成秒级。
常见错误现象：SELECT * FROM orders ORDER BY created_at DESC LIMIT 1000000, 20 执行缓慢、CPU 占用高、主从延迟加剧。
- 不是所有排序字段都适合做分页依据；
created_at有重复值时，结果可能不稳定（同秒内多条记录，OFFSET 分页会漏或重） - 使用
WHERE id > ? ORDER BY id ASC LIMIT 20替代OFFSET，性能提升通常在 10 倍以上 - 如果业务允许，优先用「游标分页」（cursor-based pagination），即记录上一页最后一条的
id或复合排序键，避免依赖全局偏移
ORDER BY 必须匹配索引才能高效使用 LIMIT + OFFSET
即使加了索引，如果 ORDER BY 字段和 WHERE 条件没对齐索引顺序，MySQL 仍可能放弃索引而走全表扫描 + filesort，此时 LIMIT 不起加速作用。
例如：表上有联合索引 INDEX (status, created_at)，但你写的是 SELECT * FROM tasks WHERE status = 'pending' ORDER BY updated_at DESC LIMIT 10——updated_at 不在索引中，MySQL 无法利用该索引完成排序，就会回表+排序，再取前 10 行。
本系统经过多次升级改造，系统内核经过多次优化组合，已经具备相对比较方便快捷的个性化定制的特性，用户部署完毕以后，按照自己的运营要求，可实现快速定制会费管理，支持在线缴费和退费功能财富中心，管理会员的诚信度数据单客户多用户登录管理全部信息支持审批和排名不同的会员级别有不同的信息发布权限企业站单独生成，企业自主决定更新企业站信息留言、询价、报价统一管理，分系统查看分类信息参数化管理，支持多样分类信息，
- 检查执行计划：
EXPLAIN SELECT ...，确认type是range或ref，且Extra中不含Using filesort或Using temporary - 若需按多个字段排序，索引字段顺序必须严格匹配
ORDER BY的顺序（方向一致，除非都是 ASC） - 覆盖索引能进一步减少回表：比如只需要
id和title，就建INDEX (status, created_at, id, title)
OFFSET 超过 100 万后几乎不可靠
不只是慢的问题。当 OFFSET 极大时，MySQL 可能因内存不足触发临时表、磁盘排序，甚至在高并发下出现查询被 kill、连接超时，或者复制线程卡住。
更隐蔽的风险是数据一致性：如果分页过程中有大量 INSERT/DELETE，OFFSET 分页的结果会出现跳跃或重复（因为行物理位置变动，OFFSET 计算基准已偏移）。
- 线上系统应禁止前端传任意大的
page参数，后端强制限制OFFSET 并返回友好提示 - 替代方案不是“优化 SQL”，而是重构分页逻辑：用上次查询的末尾主键值作为下一页起点，例如
WHERE id > 1234567 ORDER BY id ASC LIMIT 20 - 对于搜索类场景，Elasticsearch 或 MySQL 8.0+ 的
WINDOW FUNCTION（如ROW_NUMBER()）可辅助生成稳定序号，但要注意窗口函数本身不解决 OFFSET 性能问题
SELECT id, title, status FROM articles WHERE status = 'published' AND id > 8765432 -- 上一页最后一条的 id ORDER BY id ASC LIMIT 20;
游标分页没法直接跳转到第 100 页，但对用户连续浏览、无限滚动等场景足够健壮；真正需要随机跳页的后台管理界面，应改用带条件过滤（如时间范围、状态筛选）来缩小数据集，再分页。
