为什么MySQL 5.7中子查询的索引效率通常低于Join关联查询？

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 改写后结果可能错，速度可能更差。