子查询分页比直接limit快，因其仅扫描主键或覆盖索引字段，避免全表/索引扫描及无效数据丢弃；正确写法需子查询带where条件并匹配联合索引最左前缀，否则仍会全表扫描。
子查询分页为什么比直接 LIMIT 快？
因为 LIMIT 1000000, 20 不是“跳到第1000001行”，而是让 MySQL 扫描并丢弃前1000000行——全表扫描或全索引扫描，type = ALL 或 type = index，IO 和 CPU 全浪费在无效数据上。而子查询 SELECT id FROM table ORDER BY id LIMIT 1000000, 20 只查主键（或覆盖索引字段），B+树叶子节点顺序遍历，不回表、不读大字段，毫秒级完成。
正确写法：JOIN + 子查询必须带 WHERE 条件和联合索引
漏掉 WHERE 或没建对索引，整个优化就失效。常见错误是子查询里没加业务过滤条件，导致它自己先扫全表。
- 错误示范：
SELECT u.* FROM users u INNER JOIN (SELECT id FROM users ORDER BY id LIMIT 1000000, 20) tmp ON u.id = tmp.id—— 子查询没WHERE status = 1，直接全表扫 - 正确写法：子查询必须包含和外层一致的过滤条件，且该条件要落在联合索引最左列，例如
WHERE status = 1 ORDER BY id对应索引CREATE INDEX idx_status_id ON users(status, id) - 如果排序字段不是主键（比如按
updated_at），必须建(updated_at, id)联合索引，并在子查询中严格写成ORDER BY updated_at, id
性能陷阱：SELECT * 和字段膨胀会拖慢回表
子查询只取 ID 是快的，但外层 SELECT * 会让 MySQL 对每个 ID 做一次回表——字段越多、行越宽，网络和内存开销越大。
- 若只需
id, name, email，外层直接写SELECT id, name, email，避免加载无用字段 - 更进一步：把常用查询字段加进联合索引，做成覆盖查询，例如
CREATE INDEX idx_status_id_name_email ON users(status, id, name, email)，子查询就能直接返回全部字段，彻底免回表 - 注意：索引宽度增加会影响写入性能和内存占用，需权衡
什么时候子查询分页也不行？
它不是银弹。当 offset 大到几十万甚至百万，即使走索引，B+树深度和页遍历次数也会明显上升；更关键的是，一旦数据分布倾斜或索引失效，性能会断崖下跌。
-
WHERE status = 1实际只命中 0.1% 的数据，但idx_status_id索引仍有效；可如果status值高度倾斜（比如 99% 都是 1），MySQL 优化器可能放弃走索引，改用全表扫描 - ORDER BY 含函数（如
ORDER BY ABS(id)）或表达式，索引必然失效，子查询退化为 filesort + 全扫描 - 前端是无限滚动（Feed 流），用户永远只点“下一页”——此时游标分页（
WHERE (updated_at, id) > (?, ?)）响应时间恒定，比子查询更稳
真正卡住性能的，从来不是多一层 JOIN，而是子查询里那个 WHERE 条件有没有被索引覆盖、排序字段是否能触发索引有序扫描——少建一个联合索引，整套优化就停在第一步。
