MySQL 5.7中延迟关联易失效，因其优化器不自动下推子查询至索引扫描阶段，需显式用STRAIGHT_JOIN、严格联合索引（WHERE字段+ORDER BY字段+主键）、子查询仅取id并主键JOIN才能保障覆盖索引生效。
MySQL 5.7 中延迟关联不会自动生效，必须显式构造、严格索引、强制连接顺序，否则 EXPLAIN 里看到的仍是 type: ALL 或 Using filesort。
为什么 MySQL 5.7 的延迟关联容易失效
5.7 的优化器不主动下推子查询到索引扫描阶段，哪怕你写了 SELECT id FROM t WHERE ... ORDER BY ... LIMIT，它也可能把子查询物化成临时表，或重排执行顺序，导致覆盖索引失效、回表暴增。这不是写法错，而是版本限制——你得手动“扶它一把”。
-
STRAIGHT_JOIN必须加在INNER JOIN前，强制外层主表先不参与计算，等子查询结果出来再精准匹配 - 子查询里不能出现任何函数，比如
WHERE DATE(create_time) = '2026-01-01'，哪怕create_time有索引，也会退化为全表扫描 - 联合索引必须包含
WHERE字段 +ORDER BY字段 + 主键（如(status, create_time, id)），少一个字段，子查询就无法仅靠索引返回id
延迟关联 SQL 必须满足的三个硬条件
缺一不可，否则和普通 LIMIT 没区别：
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 子查询只查
id（或唯一主键），不能带*、不能查created_at等业务字段，否则失去覆盖索引优势 -
ORDER BY字段必须有索引支撑，且该索引要能同时满足WHERE过滤和排序——例如WHERE status = 1 ORDER BY create_time DESC，就得建INDEX(status, create_time, id)，而不是单列索引 - 外层必须用
INNER JOIN ... ON t.id = tmp.id（或USING(id)），绝不能写成WHERE t.id IN (SELECT ...)；后者在 5.7 下极易触发嵌套循环或临时表
怎么验证延迟关联真生效了
别信执行时间，先看 EXPLAIN 输出是否同时满足这三点：
- 子查询那行的
type是range或index（不是ALL），说明WHERE条件走了索引 - 子查询那行的
Extra包含Using index（不是Using filesort），说明排序直接用了索引有序性，没额外排序 - 外层主表那行的
type是eq_ref（主键 JOIN）或ref（唯一索引 JOIN），不是ALL或index，说明回表是 10 次精准查找，不是扫全表
存储过程里用延迟关联的致命陷阱
在 CREATE PROCEDURE 里直接拼 LIMIT p_offset, p_size 是高危操作：每次调用都重解析，大 offset 下优化器容易误判，索引突然失效。更隐蔽的问题是参数类型不一致——比如字段是 TINYINT，你传字符串 '1'，就会触发隐式转换，idx_status_created 彻底作废。还有人用 CONCAT + EXECUTE 拼 SQL，结果慢查询日志里看不到真实语句，DBA 无法定位，执行计划也无法复用。
