limit offset, size 在大数据量下变慢是因为mysql需顺序扫描前offset+size行再丢弃，innodb无跳过能力，导致io和cpu开销随offset线性增长；即使有索引，仍需逐条遍历并回表，explain显示rows剧增、extra出现using filesort。
为什么 LIMIT offset, size 在大数据量下会越来越慢
MySQL 执行 LIMIT 99990, 10 时，并不是“跳过前 99990 行”，而是先按 ORDER BY 排出至少 100000 行，再丢弃前 99990 行——扫描行数随 offset 线性增长。哪怕排序字段有索引，InnoDB 仍需逐条遍历索引树并回表取数据，IO 和 CPU 开销陡增。
典型现象：EXPLAIN 显示 rows 高达几十万，Extra 出现 Using filesort 或大量 Using index 扫描；接口响应从毫秒级升至数秒甚至超时。
- 偏移量超过 1 万，性能衰减明显，不建议继续用原生
LIMIT -
ORDER BY字段没索引？必然触发Using filesort，无论 offset 多小都慢 - 即使有索引，
SELECT *会导致大量回表，放大 IO 压力
主键 WHERE 分页（滚动分页，推荐用于列表场景）
适用于前端只有“上一页/下一页”、不支持跳页的场景。核心是用上一页最后一条记录的主键值做边界过滤，绕过 offset 扫描。
示例：按 id DESC 分页，第一页查出最小 id（即最后一条），下一页用 WHERE id ：
SELECT id, order_no, total_amount FROM `order` ORDER BY id DESC LIMIT 10;
SELECT id, order_no, total_amount FROM `order` WHERE id
- 必须确保
ORDER BY字段是主键或唯一有序字段（如自增id），否则结果可能漏行或重复 - 不能跳页，但百万级数据下稳定在毫秒级，无性能衰减
- 注意降序时用
、升序时用 <code>>，别写反
子查询先取 ID 再 JOIN（支持跳页，适合管理后台）
当产品要求支持“跳转到第 1000 页”时，用子查询只走索引读取主键，再关联查完整数据，避免全字段扫描。
写法关键点：子查询只 SELECT id，且外层 JOIN 而非 IN（MySQL 不允许子查询中直接用 LIMIT 配合 IN）：
SELECT o.* FROM `order` o INNER JOIN ( SELECT id FROM `order` ORDER BY id DESC LIMIT 99990, 10 ) t ON o.id = t.id;
- 子查询走覆盖索引（如
PRIMARY KEY），几乎不回表 - 外层
JOIN比IN更可控，执行计划更稳定 - offset 超过 10 万后，性能仍会缓慢下降，但比原生
LIMIT好得多
覆盖索引 + 只查必要字段（极致减少 IO）
如果列表页只展示几个字段（比如 id、order_no、status），把它们全塞进一个复合索引，让查询完全走 Using index，彻底避免回表。
建索引示例：
ALTER TABLE `order` ADD INDEX idx_id_basic (id, order_no, total_amount);
对应查询：
SELECT id, order_no, total_amount FROM `order` ORDER BY id DESC LIMIT 99990, 10;
- 必须确保
SELECT字段全部命中索引列，且顺序与索引定义一致（尤其排序字段要放最左） - 索引越宽，写入和维护成本越高，别滥用；仅对高频分页字段建
- 配合
WHERE条件时，注意索引最左匹配原则，ORDER BY字段得能走索引范围扫描
真正卡住人的从来不是“怎么写 LIMIT”，而是没想清楚业务是否真需要跳页、有没有缓存总数、排序字段有没有被索引覆盖。滚动分页看似受限，但在绝大多数列表场景里，它才是唯一能扛住百万数据的解法。
