延迟关联能将回表次数从百万级降至10次，因其先用覆盖索引（如type+id联合索引）只查主键ID，再通过INNER JOIN对目标ID精确回表；若索引不匹配或子查询触发filesort，则优化失效。
延迟关联不是“加个JOIN就能提速”，它只在特定索引结构+明确查询模式下生效；没配对的复合索引，写得再标准也白搭。
为什么直接 LIMIT offset, size 在百万数据后会卡住
MySQL 不支持跳行，LIMIT 1000000, 20 的实际执行是：先按 ORDER BY 排出至少 1000020 行，逐行计数，丢弃前 1000000 行，再返回剩下 20 行。如果排序字段没覆盖索引，每行都要回表读完整记录——IO 次数直接飙到 100 万+ 级别。
- EXPLAIN 中
rows值接近offset + size，且Extra出现Using filesort或Using temporary，基本可判定已掉坑 -
SELECT *+ 大字段（如TEXT、BLOB）会让无效 I/O 成倍放大 - 即使有
id主键索引，ORDER BY created_at LIMIT ...仍可能走全表扫描——除非created_at单独或组合索引能支撑排序
延迟关联的正确 SQL 写法和索引要求
核心是两段分离：子查询只走索引捞 id，外层用这 20 个 id 精准回表。但前提是子查询本身不能触发文件排序。
- 复合索引必须包含：WHERE 条件字段 → ORDER BY 字段 → 主键（按顺序），例如
ALTER TABLE orders ADD INDEX idx_status_ctime_id (status, created_at, id) - 子查询必须显式使用该索引字段，且不带函数/表达式：
SELECT id FROM orders WHERE status = 'shipped' ORDER BY created_at DESC, id DESC LIMIT 1000000, 20 - 外层 JOIN 必须用主键等值连接：
SELECT o.* FROM orders o INNER JOIN (...) AS tmp ON o.id = tmp.id - MySQL 5.7 及更早版本可能不自动优化子查询，可加
STRAIGHT_JOIN强制执行顺序
哪些情况会让延迟关联彻底失效
它不是通用银弹，几个典型翻车点容易被忽略：
-
ORDER BY字段含大量NULL值，且索引未声明IS NULL处理逻辑，排序结果不稳定 - 子查询里用了
ORDER BY DATE(created_at)这类函数，索引失效，退化为文件排序 - 业务需要精确总条数，延迟关联不解决
COUNT(*)；SQL_CALC_FOUND_ROWS在 MySQL 8.0+ 已废弃，得单独查或缓存 - 排序字段非单调（比如多个记录
created_at完全相同），又没把主键作为第二排序字段，子查询可能漏数据或重复
对比游标分页：什么时候该换方案
延迟关联保留跳页能力（比如直接输第 500 页），但性能随 offset 增长缓慢下降；游标分页性能恒定，但只能上下翻。
- 后台管理类系统（需支持页码输入、搜索后跳转）：优先用延迟关联 + 合理索引
- 用户端瀑布流、消息列表：直接上游标分页，用
WHERE (created_at, id) > ('2024-01-01', 999)这类复合条件防重复 - 混合场景（前 100 页支持跳页，之后强制滚动）：可在应用层做路由，小
offset用普通 LIMIT，大offset切游标
真正容易被忽略的是索引顺序和排序稳定性——哪怕只差一个字段位置，或者没处理 NULL 和重复值，延迟关联就只剩“看起来像优化”的假象。
