子查询分页有时更慢，根本原因是MySQL仍需遍历约10万索引节点定位起始ID，且10次回表引发随机IO；仅当表结构轻、排序字段有覆盖索引、偏移极大而每页条数极少时才有效。
子查询分页（如 SELECT * FROM t1 JOIN (SELECT id FROM t1 ORDER BY id LIMIT 100000, 10) t2 ON t1.id = t2.id）在数据量大、行宽高时可能比直接 LIMIT OFFSET 还慢，根本原因不是“没走索引”，而是它引入了额外的 server 层与引擎层交互开销，且无法规避扫描前 N 行的逻辑。
为什么延迟关联子查询有时更慢？
很多人误以为子查询只扫索引就一定快，但实际执行中：
- 子查询
SELECT id FROM t1 ORDER BY id LIMIT 100000, 10确实只读索引，但 MySQL 仍需定位到第 100001 条索引记录——B+ 树仍要遍历约 100000 个节点，尤其当索引页不在 buffer pool 时，会触发大量随机 IO； - 主查询再用这 10 个
id回表查完整行，若表行很大（比如含TEXT、BLOB字段），这 10 次回表就是 10 次随机磁盘访问，性能雪上加霜； - 整个流程涉及两次网络/内存拷贝：第一次传 10 个
id，第二次传 10 行完整数据，server 层调度成本被低估； - 如果
ORDER BY字段不是主键（比如按created_at排序），子查询本身就要 filesort 或临时表，优化彻底失效。
什么情况下子查询分页才真有效？
它只在非常特定的条件下有收益，不是通用解法：
- 表结构极轻：只有几个小字段（如
id、status、updated_at），且id是主键或聚簇索引 —— 此时回表几乎无开销； - 排序字段有高效索引，且该索引是覆盖索引（例如
INDEX(created_at, id)），子查询可完全走索引不回表； - 偏移量极大（>100 万）、但每页条数极小（如
LIMIT 1），此时子查询能显著减少传输数据量； - 你已确认
EXPLAIN中子查询的type是index或range，且rows明显小于直接LIMIT OFFSET的预估扫描行数。
比子查询更稳的替代方案
遇到子查询分页变慢，优先考虑这些落地更可靠的路径：
- 改用键集分页（keyset pagination）：
SELECT * FROM t1 WHERE created_at —— 它完全跳过 offset 计算，依赖上一页末尾值做条件过滤； - 强制使用覆盖索引 + 延迟关联，但只取必要字段：
SELECT t1.id, t1.name, t1.status FROM t1 INNER JOIN (SELECT id FROM t1 ORDER BY id LIMIT 100000, 10) t2 ON t1.id = t2.id，避免SELECT *触发大字段加载； - 对高频深度分页场景，把排序字段 + 主键建联合索引，例如
INDEX(status, created_at, id)，让子查询和主查询都能走索引下推（ICP）； - 业务允许时，用异步导出代替翻页：用户点击“导出全部”，后端走游标分批拉取，前端只展示前几页实时数据。
子查询分页容易给人一种“我优化了”的错觉，但它掩盖了最核心的问题：offset 本身不可扩展。真正要做的，不是让 LIMIT N, M 更快，而是让系统不再依赖 N。
