为什么 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显示扫描百万行才想起改表结构。
