直接结论：深分页应弃用LIMIT offset,size，改用延迟关联或游标分页。前者先查ID再JOIN，依赖覆盖索引；后者用WHERE排序字段>上页末值，要求排序字段唯一稳定，且不支持跳页。
直接结论：别再用 LIMIT offset, size 翻到百万级偏移量，它不是慢——是设计上就注定要扫完前 N 行再扔掉。修复不是调优索引，而是换执行逻辑。
为什么 LIMIT 1000000, 20 比 LIMIT 0, 20 慢几十倍
MySQL 不会“跳”到第 1000001 行。它得从头开始按 ORDER BY 字段逐行扫描、计数、丢弃，直到凑够 1000020 条，再返回最后 20 条。这个过程带来三重硬伤：
- 大量二级索引回表（
SELECT *时尤其严重） - B+ 树叶子节点跨页遍历，I/O 次数线性增长
-
sort_buffer_size溢出后触发磁盘临时文件，CPU 和磁盘双爆
实测：570 万行表，LIMIT 800000, 20 耗时 2.1 秒；优化后降到 0.3 秒。差距不在写法炫技，而在是否绕开了偏移量扫描。
延迟关联（INNER JOIN 子查询）怎么写才有效
核心是两步拆解：先用覆盖索引查 ID，再用主键精准拉数据。前提是排序字段有索引，且主键能高效定位（如自增 id 或时间+ID 联合唯一）。
- 错误写法：
SELECT * FROM account WHERE update_time > '2020-09-19' ORDER BY update_time LIMIT 100000, 10—— 扫全量、回表 100010 次 - 正确写法：
SELECT a.* FROM account a INNER JOIN (SELECT id FROM account WHERE update_time > '2020-09-19' ORDER BY update_time LIMIT 100000, 10) tmp ON a.id = tmp.id - 必须确保子查询中
ORDER BY字段和WHERE条件能走同一索引（如idx_update_time），否则子查询本身就会全表扫描 - 如果业务要求返回字段较多，且无法加覆盖索引，这种写法仍比原 SQL 快 3–7 倍，但偏移量超 500 万后性能会再次下滑
游标分页（WHERE id > ?）落地要注意什么
这是目前唯一能让深分页性能恒定的方案，但业务上要接受“不能跳页”，只支持下一页/上一页或无限滚动。
- 基础写法：
SELECT * FROM account WHERE id > 1005000 ORDER BY id LIMIT 20—— 前提是id自增且连续，否则可能漏数据 - 更安全写法（防重复/跳号）：
SELECT * FROM account WHERE update_time >= '2023-10-01' AND (update_time > '2023-10-01' OR id > 1005000) ORDER BY update_time, id LIMIT 20 - 前端必须保存上一页最后一条的排序字段值（不止一个字段），否则在并发写入、时间相同场景下会丢记录
- 不能用于后台导出或“跳转到第 N 页”类功能，这类需求只能靠业务限制（如最多查前 200 页）或异步任务兜底
真正容易被忽略的点：延迟关联对索引依赖极强，而游标分页对排序字段的唯一性和稳定性要求极高。两者都不是开箱即用的银弹——你得先确认你的 ORDER BY 字段有没有索引、是否可能重复、是否会被更新，再决定用哪条路。没做这些判断就改 SQL，大概率修了这儿，崩了那儿。
