不能一概而论。是否可换取决于子查询类型、位置和语义：标量子查询可转JOIN+聚合或窗口函数；EXISTS/NOT EXISTS适合LEFT JOIN...IS NULL；SELECT列表中的相关子查询强行JOIN易致笛卡尔积。
子查询能直接换成 JOIN 吗？
不能一概而论。是否可换，取决于子查询的类型、位置和语义——WHERE 中的标量子查询（返回单值）通常可转为 JOIN + 聚合或窗口函数；而 EXISTS 或 NOT EXISTS 子查询更适合转为 LEFT JOIN ... IS NULL；但出现在 SELECT 列表里的相关子查询（如每行查一个统计值），强行用 JOIN 容易引发笛卡尔积或重复行。
WHERE 中的 IN 子查询怎么安全转 JOIN？
IN (SELECT ...) 看似简单，但直接 JOIN 可能放大主表行数（子查询结果有重复时）。正确做法是先去重或改用 EXISTS 语义：
- 若子查询本身无重复（如查主键），可用
INNER JOIN，但需加DISTINCT或GROUP BY防止意外重复 - 若不确定是否重复，优先用
EXISTS—— 它天然短路且语义更清晰 - MySQL 8.0+ 和 PostgreSQL 支持
LATERAL（或CROSS/OUTER APPLY），适合把“每行驱动一次子查询”的逻辑显式转为连接
SELECT 列里的相关子查询怎么处理？
比如：SELECT id, (SELECT COUNT(*) FROM orders o WHERE o.user_id = u.id) AS order_count FROM users u。这类不能简单 JOIN，否则 users 行会被复制多次。可行方案有：
- 改用
LEFT JOIN ... GROUP BY：先LEFT JOIN orders，再对users.id分组，用COUNT(orders.id)统计（注意不是COUNT(*)，否则空用户也会算成 1） - 用窗口函数（如果数据库支持）：
COUNT(*) OVER (PARTITION BY u.id)，避免连接和分组开销 - PostgreSQL/SQL Server 可用
LATERAL/APPLY保持原结构，语义最接近原子查询
性能差异主要卡在哪？
子查询和 JOIN 的执行计划可能完全不同，关键差异点在：
-
IN子查询在 MySQL 5.6 前常被物化为临时表，而JOIN更倾向走索引嵌套循环；新版本优化器已收敛，但仍有例外 -
EXISTS通常比IN更快，尤其子查询结果集大时，因为找到一条就停；对应地，LEFT JOIN ... IS NULL必须扫描全部匹配行 -
JOIN容易触发中间结果膨胀（如一对多未去重），而标量子查询天然“一行一调用”，逻辑隔离更强
真正该纠结的不是“能不能换”，而是“换完是否还等价”——尤其涉及 NULL、空集、重复值时，JOIN 很容易悄悄改变结果行数或聚合值。动手前务必用小数据集对比输出。
