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 < 10000并返回友好提示 - 替代方案不是“优化 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 页，但对用户连续浏览、无限滚动等场景足够健壮；真正需要随机跳页的后台管理界面，应改用带条件过滤（如时间范围、状态筛选）来缩小数据集，再分页。
