LIMIT 100000,10 需扫描 100010 行，因 MySQL 从头逐行计数至 offset+size 后丢弃前 offset 行；即使命中索引，回表次数仍达 100010 次，且子查询等写法若未消除 offset 扫描则无效。
为什么 LIMIT 100000,10 要扫描 100010 行
MySQL 的 LIMIT offset, size 不是“跳到第 offset 行再取 size 行”，而是“从头开始，逐行计数，直到累计读够 offset + size 行，再丢弃前 offset 行”。
这意味着：
-
LIMIT 0,10：读 10 行，返回全部 -
LIMIT 100000,10：必须先读 100010 行，再扔掉前 100000 行，只留最后 10 行 - 扫描行数 =
offset + size，和是否命中索引无关
尤其当查询带 WHERE 条件时，这个扫描发生在回表阶段：
先用二级索引（如 idx_updated_at）快速定位满足条件的主键 id，再拿着这些 id 回到主键索引一棵棵查完整行——每回一次表，就算一次磁盘 I/O。offset 越大，需要回表的 id 就越多，哪怕最终只返回 10 行。
回表次数怎么被 offset 拉高的
回表不是按“页”发生的，而是按“命中的索引记录条数”发生的。假设你查：
SELECT * FROM user WHERE age > 25 ORDER BY id LIMIT 100000, 10;
执行流程其实是：
- 用
age索引扫出所有age > 25的id（可能几万条） - 按
id排序后，取前 100010 个id - 对这 100010 个
id全部回表查完整行 - 丢弃前 100000 行，返回后 10 行
所以真正拖慢查询的，不只是“扫描多”，更是“回表多”。
哪怕加了覆盖索引（比如只查 id, age），只要 SELECT 列没被索引完全覆盖，就逃不掉回表。
哪些写法看似优化，其实没绕开 offset 扫描
很多开发者尝试用子查询或 JOIN “提前截断”，但若没切断扫描起点，依然无效：
-
❌ 错误示范（仍扫描 100010 行）：
SELECT * FROM user WHERE id IN (SELECT id FROM user WHERE age > 25 LIMIT 100000, 10);
→ 子查询里LIMIT 100000,10本身就要扫 100010 行，只是把回表推迟到了外层 ✅ 正确前提：子查询必须能走覆盖索引，且只返回
id
例如：SELECT id FROM user WHERE age > 25 ORDER BY id LIMIT 100000, 10如果age和id在同一个联合索引里（KEY idx_age_id (age, id)），就能避免回表，此时子查询才真正轻量⚠️ 更隐蔽的坑：
ORDER BY字段没索引，或用了函数/表达式，会导致排序无法利用索引，进而让整个扫描变成 filesort + 全字段扫描，offset 影响被进一步放大
真正避开 offset 的关键：把“第 N 页”转成“从某值之后取 N 条”
核心思路是放弃“我要第几页”，改问“我上次看到的最后一条，它的排序字段值是多少？”
适用前提：
- 排序列（如
updated_at或id）有索引 - 该列值在分页范围内严格单调或基本不重复（
id最稳，updated_at需配合id作第二排序）
典型写法：
SELECT * FROM user WHERE updated_at < '2025-11-05 14:22:31' ORDER BY updated_at DESC, id DESC LIMIT 10;
这样数据库直接定位到索引中 updated_at 小于该时间的位置，往后连续取 10 条，全程不依赖 offset，也不扫描无关行。
最容易被忽略的一点：
这个方案要求前端或服务端必须可靠保存上一页最后一条的排序字段值，不能靠“当前页第一条的值减一”这种估算——时间精度、并发更新、时区、索引顺序都可能导致漏数据或重复。
