SQL中JOIN与子查询性能取决于执行计划、数据分布、索引和优化器，而非语法本身；现代数据库常将等价子查询重写为JOIN；真正影响性能的是访问路径与中间结果集大小。
SQL 中 JOIN 和子查询的性能不能一概而论，关键看执行计划、数据分布、索引覆盖和优化器选择。现代数据库（如 PostgreSQL、MySQL 8.0+、SQL Server）在多数场景下会将等价的子查询自动重写为 JOIN，因此“写法不同但执行相同”很常见。真正影响性能的是底层访问路径和中间结果集大小，而非语法形式本身。
执行计划决定实际开销
数据库不会因为写了 JOIN 就一定走哈希连接，也不会因用了子查询就强制嵌套循环。优化器基于统计信息估算代价后选择最优路径：
- 若子查询可去关联化（例如
WHERE x IN (SELECT y FROM t2 WHERE ...)且内表有合适索引），优化器可能转为半连接（semi-join），性能接近 JOIN； - 若子查询含聚合或无法去关联（如相关子查询
SELECT * FROM t1 WHERE t1.a = (SELECT MAX(b) FROM t2 WHERE t2.id = t1.id)），则必须逐行求值，易产生 N×M 开销； - JOIN 若缺乏驱动表筛选条件或连接字段无索引，可能导致笛卡尔积或全表扫描，代价陡增。
中间结果集大小是核心瓶颈
无论用 JOIN 还是子查询，若某一步骤生成大量中间行（如多对多连接未加限制、子查询返回万级结果供外层过滤），I/O 和内存压力都会飙升：
- LEFT JOIN A ON B 时，若 B 表匹配行数远大于 A，结果集膨胀，后续 WHERE 或 GROUP BY 成本剧增；
- EXISTS 子查询通常比 IN 更高效，因找到首匹配即停，不构造完整结果集；
- 标量子查询（返回单值）若被重复调用（如 SELECT 中多个子查询），可能多次执行——应考虑提前物化或改用 JOIN + 窗口函数。
索引与统计信息直接影响决策质量
优化器依赖准确的行数估算来比较嵌套循环、哈希连接、归并连接的成本。若统计信息陈旧或列存在严重倾斜（如 95% 值为 NULL），可能选错算法：
- 确保连接字段、WHERE 条件字段有有效索引，且 ANALYZE / UPDATE STATISTICS 已执行；
- 对高频相关子查询，可在子查询涉及字段上建复合索引，加速每轮查找；
- 用
EXPLAIN (ANALYZE, BUFFERS)（PostgreSQL）或EXPLAIN FORMAT=TREE（MySQL 8.0+）观察真实执行路径与实际行数，比预估更可靠。
改写建议：以执行逻辑为导向，而非语法偏好
不要为“看起来更简洁”而硬套子查询，也不必迷信 JOIN 一定更快。优先按语义和可维护性写，再依执行计划调优：
- 表达“存在性判断”用 EXISTS，比 IN/NOT IN 更安全高效；
- 需取关联表单个字段（如最新订单时间），优先用 LATERAL / APPLY 或窗口函数替代相关子查询；
- 多表关联且逻辑清晰时，JOIN 易读且优化器更易合并访问路径；
- 复杂计算逻辑（如分组后取 Top-N）放在子查询中预先裁剪，可显著减少 JOIN 输入量。
不复杂但容易忽略。
