为什么 LIMIT 100000, 20
会变慢
MySQL 在执行
LIMIT offset, size时，即使只返回 20 行，也必须先扫描并跳过前 100000 行——这些行可能被读入内存、经过 WHERE 过滤、排序（如果有
ORDER BY），最后才取后 20 条。偏移量越大，无效扫描越多，I/O 和 CPU 开销越明显。
常见现象包括：响应时间从几毫秒飙升到数秒、慢查询日志频繁出现、主从延迟加剧。
关键点在于：
OFFSET不是“跳过索引位置”，而是“跳过逻辑结果行数”——只要排序或过滤逻辑不能被索引完全覆盖，就无法避免回表或全扫描。
用游标分页替代 LIMIT offset
适用于有明确排序字段（如
id或
created_at）且该字段有索引的场景。核心思路是：不依赖行号偏移，而用上一页最后一条记录的排序值作为下一页起点。 原写法（低效）：
SELECT * FROM orders ORDER BY id DESC LIMIT 100000, 20优化写法（高效）：
SELECT * FROM orders WHERE id （假设上一页最大 <code>id是 123456） 要求：排序字段必须唯一或组合唯一（否则可能漏/重），且查询条件能命中索引（
WHERE + ORDER BY字段最好共用一个联合索引） 注意：不能直接跳转到任意页，只适合“下一页”“上一页”这类线性翻页；若需跳转，可先用覆盖索引查出目标页首条记录的主键值，再二次查询
WHERE id BETWEEN
+ 覆盖索引减少回表
当必须支持跳页（比如用户输入页码），且主键连续、无大范围删除时，可预估 ID 范围缩小扫描面。
例如：已知每页 20 条，想查第 5001 页（即第 100001–100020 条），若主键
id大致均匀递增，可估算 ID 区间：
WHERE id BETWEEN 105000 AND 115000，再配合
LIMIT截断。 必须配合
ORDER BY id和
PRIMARY KEY索引，否则估算失效 更稳妥做法是先用覆盖索引查 ID：
SELECT id FROM orders ORDER BY id LIMIT 100000, 1（仍慢，但只查 ID，数据量小），拿到 ID 后再
SELECT * FROM orders WHERE id >= ? ORDER BY id LIMIT 20覆盖索引（如
INDEX(status, created_at, id)）能让
SELECT id完全走索引，不回表，大幅降低
LIMIT前半部分代价
物理分表 or 归档冷数据缓解压力
如果偏移量大源于单表数据量过大（比如千万级订单表），光靠 SQL 优化边际收益递减。
对历史数据做归档：把created_at 的数据迁出，主表只保留热数据，<code>LIMIT偏移实际作用于更小数据集 按时间/业务维度分表（如
orders_2024_q1,
orders_2024_q2），分页请求带时间条件，天然落到子表，扫描基数下降 注意：分表后跨表分页（如查最近 100 条订单）需应用层合并，不能靠单条 SQL 解决
真正难处理的是既要随机跳页、又要高并发、还要全量数据在线——这时候得接受“第 10000 页”本身就是反模式，应在产品侧限制可跳转页码，或改用搜索+筛选代替无条件翻页。
