mysql 5.7中延迟关联必须手动干预，因其优化器不自动下推子查询至索引扫描阶段，易导致覆盖索引失效、filesort或全表扫描；需显式用straight_join、严格联合索引（where字段, order by字段, 主键）、子查询仅取id并主键join来保障性能。
延迟关联为什么在 MySQL 5.7 中必须手动干预
MySQL 5.7 的优化器对子查询的执行顺序不总是可靠，SELECT id FROM ... LIMIT offset, size 子查询可能被重排或物化成临时表，导致覆盖索引失效、触发 filesort 或全表扫描。这不是 bug，而是 5.7 的已知行为限制——它不会自动将子查询“下推”到索引扫描阶段。
实操建议：
- 显式加
STRAIGHT_JOIN强制连接顺序：外层主表必须放在JOIN左侧，子查询结果集（别名）放右侧 - 子查询里避免任何函数、表达式或隐式类型转换（如
WHERE status = '1'而非status = 1，若字段是字符串） - 用
EXPLAIN验证子查询是否走了type=index或type=range，且Extra字段含Using index（表示覆盖索引生效） - 若
EXPLAIN显示子查询用了type=ALL，说明索引没命中，立刻检查WHERE和ORDER BY是否共用同一联合索引
联合索引必须按 (WHERE 字段, ORDER BY 字段, 主键) 严格排序
在 MySQL 5.7 中，索引字段顺序直接影响子查询能否跳过排序。例如查询 WHERE type = 8 ORDER BY created_at DESC，只建 INDEX(type) 或 INDEX(created_at) 都无效；必须建 INDEX(type, created_at, id)。
原因：子查询 SELECT id FROM t WHERE type = 8 ORDER BY created_at DESC LIMIT 100000, 10 要同时满足过滤 + 排序 + 覆盖，三者缺一不可。末尾的 id 不是可选项——没有它，InnoDB 无法仅靠索引叶子节点返回值，必然回表，失去“延迟”意义。
常见错误：
- 建了
(type, created_at)却忘了id→ 子查询仍需回表查id，I/O 毫无改善 - 排序字段含
NULL，但索引未声明NOT NULL→ 索引排序不稳定，分页结果错乱 -
ORDER BY created_at DESC, id DESC，但索引是(type, created_at, id)升序 → 无法复用，强制filesort
延迟关联写法必须拆成两步：子查询只取 id，外层用主键 JOIN
正确写法不是“改写原 SQL”，而是结构上强制分离：子查询负责定位，主查询负责装载。任何把业务字段塞进子查询、或用 WHERE 替代 JOIN 的写法，都会让优化失效。
示例（假设表 order_history，查 type = 8 的第 100001–100010 条）：
SELECT t1.* FROM order_history t1 INNER JOIN ( SELECT id FROM order_history WHERE type = 8 ORDER BY id LIMIT 100000, 10 ) t2 ON t1.id = t2.id;
关键约束：
- 子查询中禁止出现
t1.*或任何非id字段 -
ON条件必须是主键等值匹配（t1.id = t2.id），不能是范围或函数 - 若原查询有多个
WHERE条件（如AND status IN ('paid', 'shipped')），这些条件必须全部下推到子查询内，不能留在外层 - 不要用
LEFT JOIN——延迟关联依赖精确匹配，LEFT会引入空值和额外判断开销
游标分页比延迟关联更稳，但 5.7 下要注意 NULL 和重复值陷阱
如果业务允许连续翻页（如“下一页”按钮），直接用游标分页比折腾延迟关联更简单、性能更恒定。但在 MySQL 5.7 中，WHERE (created_at, id) > ('2023-01-01', 999) 这类复合条件需格外小心。
真实踩坑点：
-
created_at允许为NULL→NULL在ORDER BY ... DESC中排最前，但WHERE col > value会跳过所有NULL，造成漏数据 - 多个记录
created_at完全相同 → 仅靠该字段无法唯一确定顺序，必须补上id（或其它唯一列）做第二排序键 - 游标值必须来自上一次查询返回的
id字段值，不能用“当前页码 × 每页条数”反推——因为删改会导致 ID 不连续，推算结果必然错位
真正容易被忽略的是：MySQL 5.7 对 ORDER BY a DESC, b DESC 和 WHERE (a, b) > (x, y) 的索引匹配很敏感，必须确保索引定义与查询条件完全一致，包括 ASC/DESC 方向。一旦方向不匹配，索引就失效。
