LIMIT offset, size 在大数据量下变慢是因为 MySQL 必须扫描并丢弃前 offset 行，无法直接跳转；游标分页通过 WHERE sort_col > last_value + LIMIT size 实现索引范围扫描，避免跳行，性能稳定在毫秒级。
为什么 LIMIT offset, size 在大数据量下会变慢
因为 MySQL 无法跳过前 offset 行直接定位，必须扫描并丢弃前面所有行。当 offset 达到几十万甚至百万级，即使有索引，B+ 树也要逐层遍历、回表、过滤，I/O 和 CPU 开销剧增。
典型表现是执行计划中 Extra 字段出现 Using filesort 或 Using temporary，且 rows 显示扫描行数远大于 size。
- 索引仅加速“查找起点”，不加速“跳过 offset 行”
- 主键自增时，
ORDER BY id LIMIT 100000, 20仍要遍历 100020 条记录 - 复合索引
(status, created_at)上做WHERE status = 1 ORDER BY created_at LIMIT 50000, 20，MySQL 仍需定位到第 50001 条匹配记录
用游标分页（cursor-based pagination）替代 offset
核心思路：不再依赖“第 N 页”，而是记住上一页最后一条的排序字段值，用 WHERE sort_col > last_value + LIMIT size 拉取下一页。这样 MySQL 可直接走索引范围扫描，避免跳行。
前提是排序字段必须唯一且非空（推荐组合主键或加 id 保序），否则会出现漏数据或重复。
SELECT * FROM orders WHERE status = 1 AND created_at > '2024-05-01 10:23:45' ORDER BY created_at, id LIMIT 20;
- 必须在
WHERE和ORDER BY中使用相同排序字段，且顺序一致 - 如果
created_at可能重复，务必追加id（主键）作为第二排序条件，保证结果稳定 - 前端需保存上一页最后一条的
created_at和id值，下次请求带入 - 不支持“跳转任意页”，但符合无限滚动场景，性能稳定在毫秒级
覆盖索引 + 延迟关联优化传统分页
当必须支持跳页（如后台管理页码输入），可先用覆盖索引快速拿到主键，再二次关联查全量字段，减少回表开销。
SELECT o.* FROM orders o
INNER JOIN (
SELECT id FROM orders
WHERE status = 1
ORDER BY created_at DESC
LIMIT 100000, 20
) AS tmp ON o.id = tmp.id;- 内层子查询只查
id，若(status, created_at, id)是联合索引，就完全走索引，不回表 - 外层用主键
id关联，只需 20 次精确回表，比原语句少扫 10w+ 行 - 索引需包含所有
WHERE、ORDER BY和SELECT中用到的字段（至少含id） - 注意：MySQL 8.0+ 对这种写法优化更好；5.7 下建议强制使用索引：
FORCE INDEX (idx_status_created_id)
物理分表 or 时间分区应对超大单表
单表超千万行后，即使优化分页，索引深度增加、统计信息不准、锁竞争等问题也会浮现。此时分页只是表设计滞后的症状，该考虑拆分了。
按时间分区最常见，比如每月一个分区，分页逻辑改为“先查最近 N 个分区，不够再往前查”：
ALTER TABLE logs PARTITION BY RANGE (TO_DAYS(log_time)) (
PARTITION p202404 VALUES LESS THAN (TO_DAYS('2024-05-01')),
PARTITION p202405 VALUES LESS THAN (TO_DAYS('2024-06-01')),
PARTITION p_future VALUES LESS THAN MAXVALUE
);- 查询
WHERE log_time >= '2024-05-10'时，MySQL 自动裁剪只访问p202405分区 - 分页时优先在最新分区查，命中率高、数据热、索引浅
- 历史分区可归档或转为只读，降低主库压力
- 注意：分区字段必须是
WHERE条件的一部分，否则无法裁剪
游标分页的稳定性依赖排序字段的单调性和索引有效性，而分区和覆盖索引是兜底手段——别等 EXPLAIN 显示扫描百万行才想起改表结构。
