1.1 “跳过”是扫描后丢弃#

LIMIT 100000, 20 看起来是”跳过 10 万行取 20 行”，但 InnoDB 没有直接跳到第 100000 行的能力。它的实际执行过程是：从索引或数据的第一行开始，逐行扫描，扫描够 offset 行后才真正收集要返回的 count 行。

1
-- 典型深分页查询
2
SELECT * FROM orders ORDER BY id LIMIT 100000, 20;

这条语句的代价由两部分构成：

问题不在于返回的 20 行，而在于前面被丢弃的 10 万行。LIMIT 的扫描量是 offset + count，不是 count。offset 越大，无用的扫描越多，深分页越慢。

1.2 为什么扫描了还要回表#

如果查询只走覆盖索引，扫描 100020 行丢弃 10 万行，代价是 10 万次顺序读索引页，虽有开销但不致命。致命的是带 SELECT * 的查询：

1
SELECT * FROM orders ORDER BY created_at LIMIT 100000, 20;

SELECT * 需要返回所有列，二级索引 idx_created_at 不覆盖全部列。当优化器选择走 idx_created_at 时，执行计划是：沿 idx_created_at 的叶子链表顺序扫描，每扫到一行就回表聚簇索引取完整行，扫够 100020 行后返回最后 20 行。

前 10 万行全部回表，每次回表是一次聚簇索引的随机 I/O，最终这 10 万次回表全部丢弃。深分页慢的根因就在这里：offset 区间内的回表完全是白做的。

1.3 用 EXPLAIN 确认代价#

1
EXPLAIN SELECT * FROM orders ORDER BY created_at LIMIT 100000, 20;

重点看两列：

• rows：优化器估算的扫描行数，深分页场景这个值会接近 offset + count
• Extra：若出现 Using filesort，说明排序没走索引，是另一类问题（先建排序索引，再谈分页优化）

确认 rows 远大于 count 且 Extra 没有出现 Using filesort，才是典型的深分页回表问题，适用本文后续方案。注意区分两种 Extra：走索引扫描但需回表时，Extra 通常没有 Using index（覆盖索引才有）也没有 Using filesort；而优化器放弃索引、改走全表扫描加排序时，Extra 会出现 Using filesort，这属于行 70 提到的另一类问题，得先解决排序再谈分页优化。实际复现中，当 ORDER BY 列的索引选择率低（扫描行数占比高）时，优化器会判定”沿索引扫大量行再回表”比”全表扫描加 filesort”代价更高，从而选后者，这时 FORCE INDEX 才能强制走回表路径。

2.1 思路#

既然 offset 区间的回表是白做的，就把”扫描 offset 行”这一步限定在索引内完成，只对最终要返回的 count 行回表。用子查询先在覆盖索引上定位到需要的 20 个主键，再回表：

1
SELECT * FROM orders
2
WHERE id IN (
3
    SELECT id FROM (
4
        SELECT id FROM orders
5
        ORDER BY created_at
6
        LIMIT 100000, 20
7
    ) tmp
8
);

子查询只查 id（主键），可以走覆盖索引，扫描 100020 行但不回表，只在最外层对 20 个 id 回表。回表次数从 10 万次降到 20 次。

2.2 适用与限制#

这个方案对”深而窄”的分页（offset 大、count 小，比如翻页只取 20 条）效果最好。当 count 也很大时，IN 子查询的 20 变成几百上千，去重和回表的开销会重新上升。

3.1 思路#

延迟关联是子查询方案的演进。把子查询和主表 join，而不是用 IN，规避 IN 子查询对结果集大小敏感的问题：

1
SELECT t.* FROM orders t
2
INNER JOIN (
3
    SELECT id FROM orders
4
    ORDER BY created_at
5
    LIMIT 100000, 20
6
) tmp ON t.id = tmp.id;

子查询 tmp 在覆盖索引上定位 20 个主键，外层 join 用主键等值匹配回表取完整行。本质和方案一相同，但 join 的执行计划对 MySQL 优化器更友好，count 较大时稳定性优于 IN。

3.2 与子查询方案的对比#

生产中 count 不固定或可能变大的分页接口，倾向用延迟关联。

4.1 思路#

如果返回的列不多，可以直接建一个覆盖这些列的联合索引，让查询完全不回表：

1
-- 列表页只需 id、标题、创建时间
2
SELECT id, title, created_at FROM orders
3
ORDER BY created_at
4
LIMIT 100000, 20;

1
-- 建覆盖索引
2
CREATE INDEX idx_created_at_cover ON orders (created_at, id, title);

查询沿 idx_created_at_cover 的叶子链表顺序扫描，所需列全在索引里，全程不回表。扫描 10 万行的代价还在，但每次扫描是顺序读紧凑的索引页，没有随机 I/O，比回表快一个量级。

4.2 适用边界#

这个方案用空间换时间。适合列表页返回字段稳定且不多（比如管理后台的订单列表只展示 5~6 个字段）的场景。返回列多到接近整行时，索引体积逼近数据本身，不如用延迟关联。

5.1 思路#

前三种方案都在优化”扫描 offset 行后丢弃”这件事，但 offset 区间的扫描本质上无法消除。游标分页换了个思路：不再用 offset，改用上一页最后一条记录的值作为下一页的起点。

1
-- 第一页
2
SELECT id, created_at FROM orders
3
ORDER BY created_at, id
4
LIMIT 20;
5

6
-- 第二页起：传入上一页最后一条的 (created_at, id)
7
SELECT id, created_at FROM orders
8
WHERE created_at > '2026-07-01 10:00:00'
9
   OR (created_at = '2026-07-01 10:00:00' AND id > 12345)
10
ORDER BY created_at, id
11
LIMIT 20;

下一页的查询条件变成了 WHERE 范围扫描，直接从上一页终点开始，扫描量恒为 count，与页码无关。翻到第 1000 页和翻到第 2 页，单页查询代价相同。

5.2 为什么排序要带上主键#

created_at 可能有大量同值记录。如果排序条件只有 created_at，游标 created_at > 上一页值 会漏掉同一秒内排在后面的记录，或重复返回。加上 id 作为 tiebreaker，排序键变成 (created_at, id) 唯一，游标定位精确，分页不重不漏。

5.3 适用与限制#

游标分页是性能最优的方案，代价是牺牲”跳页”能力。微博时间线、朋友圈这类只能往下刷的场景，天然适合。需要提供页码跳转的后台管理界面，则不适合。

7.1 排序的稳定性#

分页要求数据顺序稳定：同一查询翻页时，记录不会因为并发增删而在页间漂移。ORDER BY 的列如果不唯一，MySQL 对同值行的顺序不保证稳定，游标分页会因此漏数据或重复。解决方法是排序键加主键保证唯一，前文的 (created_at, id) 就是这个目的。任何分页方案，排序键不唯一都是隐患。

7.2 分页总数与总数展示#

列表页常显示”共 12800 条，第 5/640 页”。算总数用 SELECT COUNT(*)，在大表上是全表或全索引扫描，代价不低。几种取舍：

• 不显示精确总数：只显示”加载更多”或”上一页/下一页”，配合游标分页
• 显示近似总数：用 EXPLAIN 的 rows 估算值，或缓存定期刷新的总数
• 显示精确总数：只能 COUNT(*)，大表建议加缓存，避免每次翻页都算

精确总数与深分页往往冲突：游标分页没有总页数的概念，强制显示精确总数会抵消游标分页的性能优势。这是产品需求和技术成本的取舍，不是纯技术问题。