JOIN 和 IN/EXISTS 并不存在绝对意义上的“谁一定更快”，真正决定性能的，还是执行计划本身：会不会触发 DEPENDENT SUBQUERY，中间结果集有没有明显膨胀，以及连接字段是否建立了索引。只要出现 DEPENDENT SUBQUERY，性能往往就容易失控；这时候更稳妥的做法，是改写成半连接，或者确保索引能够完整覆盖。

JOIN 和 IN / EXISTS 子查询没有绝对快慢，真正起决定作用的是执行计划是否触发 DEPENDENT SUBQUERY、中间结果集是否膨胀、连接字段有没有索引。

看到 DEPENDENT SUBQUERY 就该立刻警惕

这是 MySQL / PostgreSQL 执行计划里最危险的信号。它意味着外层每查一行，内层子查询就得重跑一次。

• 比如 SELECT * FROM users u WHERE EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id)，如果 users 有 50 万行，orders 缺少 (user_id) 索引，实际就是 50 万次单行扫描
• EXPLAIN 输出中只要出现 select_type = DEPENDENT SUBQUERY，基本等于性能已失控，必须改写
• 这种场景下，LEFT JOIN 或 EXISTS 改写为半连接（semi-join）通常更稳——但前提是优化器能识别且没被禁用

IN 子查询在 MySQL 5.6+ 常被自动转成 semi-join

只要你写的 IN 子查询满足几个简单条件：不带 GROUP BY、不带 LIMIT、不带 ORDER BY、子查询字段有索引，MySQL 优化器大概率把它重写成和 JOIN 几乎一样的执行路径。

• EXPLAIN 里可能看到 type: eq_ref 或 Using join buffer，说明已走半连接，性能与等价 JOIN 拉不开差距
• 但如果子查询里写了 SELECT DISTINCT user_id FROM orders GROUP BY user_id，优化器直接放弃重写，退化为逐行物化，性能断崖下跌
• NOT IN 几乎从不被转成 semi-join，尤其当右表含 NULL 时还会逻辑错误，一律优先换 NOT EXISTS

中间结果集大小比语法形式更致命

一个 LEFT JOIN 把 1 万用户 × 平均 200 订单 = 200 万行中间结果，后续再 GROUP BY 或 ORDER BY，内存和排序压力远超一个只返回布尔值的 EXISTS。

• 标量子查询（如 SELECT name, (SELECT MAX(created_at) FROM logs l WHERE l.user_id = u.id)）若 logs(user_id, created_at) 有复合索引，实际走索引 MIN/MAX 查找，比 JOIN + GROUP BY 更轻量
• DISTINCT 在 JOIN 后补救重复行，常引发 Using temporary 和 Using filesort，不如一开始就用 EXISTS 表达存在性语义
• 多对多关联未加限制（如学生×课程×成绩三表连查）极易膨胀，此时先用子查询物化中间结果（WITH 或临时表）反而可控

索引失效会让所有写法都变慢

无论你写 JOIN 还是 IN，只要 ON 或 WHERE 条件字段没走索引，全表扫描开销就盖过一切语法差异。

• INNER JOIN t1 ON t1.a = t2.a 中，t2.a 没索引 → 退化为嵌套循环，和相关子查询实际执行路径差不多
• 复合索引顺序错位（如查询 WHERE user_id = ? AND created_at > 却建了 (created_at, user_id)）→ 索引完全失效
• EXISTS 内层依赖外层字段时，那个字段必须有索引；否则仍是全表扫，EXISTS 的“短路”优势归零

很多人优化 SQL 时，最容易漏看的，恰恰是 rows 字段和 Extra 里那些很直白的信号：比如 Using temporary、Using filesort，再比如 Rows_examined 明显高得离谱。真正把性能拖慢的，往往就是这些硬指标，而不是反复争论到底该写 JOIN 还是 IN。

《夸克》非常好用的免费AI浏览器

下载APP查看