MySQL 5.7中子查询常导致外层索引失效，根本原因是优化器对相关子查询采用逐行驱动策略，即每扫描主表一行就重复执行子查询，使外层WHERE无法利用索引定位，EXPLAIN显示DEPENDENT SUBQUERY即为典型标志。
MySQL 5.7 中子查询常无法利用外层表索引，根本原因是优化器对非物化相关子查询采用“逐行驱动”策略，而非先物化再匹配。
EXPLAIN 出现 DEPENDENT SUBQUERY 就意味着索引失效
只要子查询里引用了外层表字段（比如 u.id = o.user_id），MySQL 5.7 基本不会物化它，而是标记为 DEPENDENT SUBQUERY。这意味着：
- 主表每扫描一行，就触发一次子查询执行
- 外层 WHERE 条件无法走索引定位，只能全表扫或索引全扫描
- 执行计划中常见 type: ALL 或 Extra: Using where; Using join buffer
IN/=/NOT IN 子查询让外层索引“形同虚设”
这类子查询在 5.7 中几乎必然触发先执行后匹配流程：
- 优化器先执行 SELECT user_id FROM logs WHERE status = 1，可能全表扫生成临时结果集
- 再拿这个结果集去匹配主表，此时主表的 id 字段即使有索引也用不上
- 即使子查询本身能走索引，外层表仍被迫做 ALL 扫描
- NOT IN 还额外受 NULL 传染：只要子查询返回任意 NULL，整个条件恒为 FALSE
JOIN 能下推条件、复用索引、避免重复计算
改写为 JOIN 后，优化器可统一规划执行路径：
- 把 logs.status = 1 直接下推到 logs 表扫描时过滤，减少中间结果
- 若 orders.user_id 和 logs.user_id 都有索引，可用 Index Nested-Loop Join 快速匹配
- 不会为每一行订单重复打开、解析、执行子查询逻辑
- 无临时表创建/销毁开销，也不会因子查询里的 ORDER BY RAND() 或 GROUP BY 导致物化失败
不是所有子查询都能安全 JOIN 化
强行替换可能出错，必须核对三件事：
- 连接字段是否都有索引：orders.user_id 和 users.id 缺一不可，否则 JOIN 反而更慢
- NULL 怎么处理：LEFT JOIN ... IS NULL ≠ NOT EXISTS，若右表连接列允许 NULL，得补 AND right.id IS NOT NULL
- 行数是否膨胀：一对多关系（如订单→订单项）直接 JOIN 会重复主表行，要用 DISTINCT 或改用 EXISTS
真正卡住性能的，往往不是语法写法本身，而是没看清子查询是否真“相关”、有没有隐式聚合、连接字段是否为空——这些细节漏掉一个，JOIN 改写后结果可能错，速度可能更差。
