子查询性能差因重复扫描、索引失效或临时表膨胀，尤其相关子查询每行执行一次；JOIN一次性连接，优化器更易选驱动表、用索引、批量处理。
为什么子查询性能差，而JOIN通常更快
MySQL执行子查询时，常出现重复扫描、无法利用索引或临时表膨胀等问题。尤其是 WHERE ... IN (SELECT ...) 或 WHERE ... = (SELECT ...) 这类相关子查询，在外层每行都要执行一次内层查询。JOIN则能一次性建立连接关系，让优化器更易选择驱动表、使用索引和批量处理。
- 相关子查询（含
WHERE t1.id = t2.id 这类引用外层字段的）几乎总能转为 INNER JOIN 或 LEFT JOIN
- 非相关子查询（如
(SELECT MAX(created_at) FROM logs)）一般无需改写，它只执行一次，改JOIN反而画蛇添足
-
EXISTS 子查询多数情况可转为 LEFT JOIN ... ON ... WHERE t2.id IS NOT NULL，但需注意语义是否等价（比如去重逻辑）
把 WHERE IN (SELECT ...) 改成 INNER JOIN 的实操步骤
这是最常见也最容易出错的改写场景。核心原则是：用 INNER JOIN 替代过滤逻辑，并用 DISTINCT 或 GROUP BY 消除因一对多导致的重复行。
SELECT u.name FROM users u
WHERE u.id IN (SELECT user_id FROM orders WHERE status = 'paid');
WHERE t1.id = t2.id 这类引用外层字段的）几乎总能转为 INNER JOIN 或 LEFT JOIN
(SELECT MAX(created_at) FROM logs)）一般无需改写，它只执行一次，改JOIN反而画蛇添足EXISTS 子查询多数情况可转为 LEFT JOIN ... ON ... WHERE t2.id IS NOT NULL，但需注意语义是否等价（比如去重逻辑）INNER JOIN 替代过滤逻辑，并用 DISTINCT 或 GROUP BY 消除因一对多导致的重复行。
SELECT u.name FROM users u WHERE u.id IN (SELECT user_id FROM orders WHERE status = 'paid');
改写为：
SELECT DISTINCT u.name FROM users u INNER JOIN orders o ON u.id = o.user_id WHERE o.status = 'paid';
- 必须加
DISTINCT（或GROUP BY u.id），否则一个用户多笔订单会导致名字重复 -
ON条件必须严格对应原子查询的关联字段，不能漏掉o.user_id IS NOT NULL等隐含约束 - 若原查询有
ORDER BY或LIMIT，改写后仍需保留，但位置可能影响执行计划——建议先加EXPLAIN对比
把 WHERE NOT IN (SELECT ...) 改成 LEFT JOIN ... IS NULL 时的关键陷阱NOT IN 遇到子查询结果含 NULL 会整个返回空集，这是 SQL 标准行为，但 LEFT JOIN ... IS NULL 不受此影响，语义不等价。
SELECT name FROM users
WHERE id NOT IN (SELECT user_id FROM banned_users);
如果 banned_users.user_id 允许为 NULL，上面语句永远不返回任何行。安全改写必须先排除 NULL：
SELECT u.name FROM users u LEFT JOIN banned_users b ON u.id = b.user_id AND b.user_id IS NOT NULL WHERE b.user_id IS NULL;
- 一定把
b.user_id IS NOT NULL放在ON子句里，而非WHERE—— 否则就退化成INNER JOIN - 更稳妥的做法是先确认子查询字段是否允许
NULL：SHOW COLUMNS FROM banned_users LIKE 'user_id'; - 若业务上确定无
NULL，可直接用LEFT JOIN ... WHERE b.user_id IS NULL
什么时候不该硬改 JOIN
不是所有子查询都适合或值得改写。以下情况保持原样更清晰、更安全：
- 子查询只执行一次且结果集极小（如
(SELECT 100) 或查配置表单行）
- 使用了窗口函数或
GROUP_CONCAT 等无法被 JOIN 自然替代的聚合逻辑
- 原查询已加了合适的索引，
EXPLAIN 显示 type=eq_ref 或 const，实际执行很快
- JOIN 后需要大量
DISTINCT 或 GROUP BY，导致排序/临时表开销反超子查询
(SELECT 100) 或查配置表单行）GROUP_CONCAT 等无法被 JOIN 自然替代的聚合逻辑EXPLAIN 显示 type=eq_ref 或 const，实际执行很快DISTINCT 或 GROUP BY，导致排序/临时表开销反超子查询真正要盯住的，是那些 EXPLAIN 中出现 type=ALL、Extra: Using temporary; Using filesort 或子查询显示 select_type=DEPENDENT SUBQUERY 的慢查询。这些才是改写的优先目标。
