子查询常比JOIN慢，因MySQL 5.7及更早版本难以优化相关子查询，易导致每行主表重复执行；而JOIN可利用Hash Join、索引嵌套循环等高效路径，并支持提前过滤。
为什么子查询经常比JOIN慢
MySQL（尤其是5.7及更早版本）对大多数相关子查询（correlated subquery）无法有效下推条件或重用索引，执行时可能对主表每行都触发一次子查询，形成嵌套循环。而JOIN在优化器能识别连接条件和索引时，通常走Hash Join或Index Nested-Loop，并支持提前过滤、排序合并等优化路径。
常见错误现象包括：EXPLAIN 显示 type 为 ALL 或 index，Extra 出现 Using where; Using temporary; Using filesort，且 rows 列数值远超实际结果集大小。
- 相关子查询（如
WHERE id IN (SELECT user_id FROM logs WHERE status = 'error')）容易被重复执行 - 子查询返回多列或多行时，MySQL可能无法物化中间结果，导致反复计算
- 某些场景下，即使子查询带
LIMIT 1，优化器仍不将其转为半连接（semi-join），需显式提示
哪些子查询可以安全改写为JOIN
不是所有子查询都适合改写——核心判断标准是语义是否等价、是否引入重复行、是否改变 NULL 行处理逻辑。
可直接改写的典型场景：
-
IN/EXISTS子查询，且子查询只查单列、无聚合、无GROUP BY -
NOT IN改为LEFT JOIN ... WHERE right.id IS NULL，但必须确认子查询结果不含NULL（否则逻辑错） - 子查询用于字段计算（如
(SELECT name FROM users u WHERE u.id = o.user_id)），可转为JOIN users u ON o.user_id = u.id
不能直接改写的情况：
- 子查询含
ORDER BY + LIMIT（如取每个用户的最新订单），需用窗口函数或派生表先聚合 - 子查询有聚合（
COUNT(*)、SUM()）且未关联分组键，改JOIN后需加GROUP BY并小心去重 - 主表与子查询表存在一对多关系，直接JOIN会放大主表行数，应考虑用
DISTINCT或GROUP BY控制
改写时必须检查的三个细节
改写不是机械替换，漏掉任一细节都可能导致结果错误或性能更差。
- 确认连接字段的索引存在：主表
user_id和子表id都要有单独索引或联合索引，否则JOIN反而变慢 - 处理NULL逻辑：
NOT EXISTS对NULL安全，但LEFT JOIN ... IS NULL要求子表连接字段非NULL；若子表该字段允许NULL，需额外加AND right.id IS NOT NULL - 控制行数膨胀：例如
SELECT o. FROM orders o JOIN order_items i ON o.id = i.order_id会为每个订单项返回一行订单，若只需订单信息，应加DISTINCT o.或改用EXISTS
示例对比：
原慢查询：
SELECT <em> FROM users u WHERE u.id IN (SELECT user_id FROM events WHERE type = 'login' AND created_at > '2024-01-01');</em>
改写后：
SELECT DISTINCT u. FROM users u INNER JOIN events e ON u.id = e.user_id WHERE e.type = 'login' AND e.created_at > '2024-01-01';
注意这里用了 DISTINCT，因为一个用户可能有多次登录事件。
EXISTS vs JOIN：什么时候该选哪个
EXISTS 和 JOIN 在语义和性能上并不总等价，选错可能绕回原问题。
- 若只判断“是否存在”，优先用
EXISTS：它天然短路，找到第一行即停，且不放大行数，EXPLAIN中常显示type=eq_ref或type=ref - 若还需子表字段（如
e.created_at），必须用JOIN，但要注意是否需要GROUP BY或LIMIT控制 - MySQL 8.0+ 开启了 semi-join 优化，默认会将部分
IN/EXISTS自动转为 JOIN，但可通过SET optimizer_switch='semijoin=off'关闭来对比效果
真正容易被忽略的是：JOIN 改写后，如果连接条件没走索引，性能可能比原子查询还差——务必在改写前后都跑 EXPLAIN FORMAT=JSON 对比 rows_examined 和 used_columns。
