SQL 中的 JOIN 与子查询没有绝对的优劣之分。二者都能跨表取数，但工作方式和适用场景不同：JOIN 把多张表的行横向合并成一张宽结果集，适合需要同时返回多表列、做跨表聚合的场景；子查询把一段查询嵌套进另一段，擅长表达标量比较、存在性检查和分步逻辑。现代数据库优化器（如 PostgreSQL 10+、MySQL 8+、SQL Server 2016+）常把简单的 IN 子查询自动重写为等价的半连接执行计划，因此非相关场景下二者性能往往一致；真正的差距出现在相关子查询、NOT IN 空值陷阱等特定情况。据 SQLServerGuides 的技术分析，查询优化器的”子查询展开（Subquery Unnesting）”机制让两条写法不同的语句最终生成相同的执行计划。
一、概念本质：两种跨表取数的思路
JOIN 通过连接条件将多个表的行按列关联，产出一个包含各表字段的扁平宽表。它建立在集合运算之上，数据库引擎调用 Nested Loop、Merge Join、Hash Join 三种物理算子之一来完成匹配。
子查询（嵌套查询）是把一个 SELECT 嵌到另一个查询的 WHERE、FROM 或 SELECT 子句中。按执行方式可分为两类：非相关子查询只执行一次；相关子查询引用外层列，理论上对外层每一行都要重跑一次。据腾讯 ima 知识库的整理，执行计划中出现的 DEPENDENT SUBQUERY 标记即代表相关子查询的逐行执行，是需要重点优化的信号。
二、核心差异对比
下表从多个维度拆解二者的特性（综合 Dev.to、SQLabHub、CSDN 等资料）：
| 对比维度 | JOIN | 子查询 |
|---|---|---|
| 核心逻辑 | 多表行横向合并为宽结果集 | 一段查询结果作为另一段的条件或数据源 |
| 返回形态 | 扁平宽表，可能含重复行 | 可返回标量、单列、多列，作为中间数据 |
| 性能倾向 | 通常高效，优化器可生成 Hash/Merge Join | 相关子查询可能逐行执行，开销大 |
| 可读性 | 多表关系直观 | 分步逻辑、复杂过滤更清晰 |
| 暴露列能力 | 可 SELECT 任意连接表字段 |
WHERE 子���询无法向外层暴露内部列 |
| 典型用途 | 多表字段联取、跨表 GROUP BY 聚合 |
EXISTS 检查、聚合比较、DML 数据源 |
三、什么时候优先用 JOIN
需要同时输出多个关联表的列时，JOIN 是唯一干净的选择。例如”列出订单及其客户姓名”，子查询无法把客户表的列暴露到外层 SELECT，必须借助 JOIN。
SELECT o.id, o.total, c.name
FROM orders o
INNER JOIN customers c ON o.customer_id = c.id;
JOIN 还在以下场景占优：大数据集且连接列有索引时，优化器能利用索引高效匹配；需要跨多表做 GROUP BY 聚合（如”每个城市的销售总额”）；数据管道、ETL 中的多表转换。据 sqlabhub 的对照，JOIN 在”需要多表列参与 SELECT“和”跨表聚合”两类任务上不可替代。
四、什么时候优先用子查询
子查询在三类场景更顺手。第一，与聚合值比较，例如”找出薪资高于全公司平均的员工”：
SELECT name, salary
FROM employees
WHERE salary > (SELECT AVG(salary) FROM employees);
第二，存在性检查，用 EXISTS 表达”是否存在相关记录”，且匹配到第一行即短路停止：
SELECT name FROM customers c
WHERE EXISTS (SELECT 1 FROM orders o WHERE o.customer_id = c.customer_id);
第三，分步逻辑与 DML，在 UPDATE/DELETE 中嵌套条件比多表语法更清晰。SQLServerGuides 给出明确规则：当比对的是单一标量基准值（如平均值、最大值）时，子查询更合适；当比对的是多组分桶聚合时，改用连接派生表性能更好。
五、性能真相：优化器如何改写二者
现代基于代价的优化器（CBO）在编译阶段会尝试把子查询”展开”成等价的 JOIN 或 SEMI-JOIN。TechMixing 2026 年的测试指出，下面两条语句在 SQL Server 中常生成相同的半连接计划，性能无差别：
SELECT * FROM A WHERE A.ID IN (SELECT ID FROM B);
SELECT * FROM A JOIN B ON A.ID = B.ID;
但改写并非总会成功。SQLServerGuides 列举了优化器无法展开的典型情况：相关子查询内嵌多层聚合、含 NEWID()/RAND() 等非确定性函数、以及 NOT IN 遇上可空列。后者尤其危险——若子查询返回任何一个 NULL，整个 NOT IN 谓词结果为 UNKNOWN，可能退回逐行校验的慢计划。遇到”找不存在的记录”，应改用 NOT EXISTS 或 LEFT JOIN ... IS NULL。
六、选型决策框架
把下述清单作为代码评审和架构设计的判断顺序：
- 结果需要另一张表的列？是 → 用 JOIN；否 → 进入下一步。
- 只做存在/不存在判断？是 → 用
EXISTS/NOT EXISTS，享受短路。 - 比对的只是单一标量（平均、最大）？是 → 子查询更清晰。
- 比对的是多组分桶聚合？是 → 先聚合成派生表再 JOIN。
- 不确定谁更快？对两条写法都跑
EXPLAIN，让执行计划说话。
这条框架与 CSDN 技术问答中”能用 JOIN 就不用子查询（性能优先），逻辑复杂时子查询更清晰（可读性优先）”的结论一致。
七、两个高频陷阱
NOT IN 的空值地雷：子查询列可空时，NOT IN 可能返回零行或触发慢计划，优先用 NOT EXISTS。
相关子查询的 N+1 隐患：外层有 N 行、子查询逐行执行，总开销接近 N 次查询。应改写为 JOIN 或派生表，让优化器一次性集合化处理。
常见问题（FAQ）
JOIN 一定比子查询快吗？
不一定。现代优化器常把简单子查询重写为等价 JOIN，二者计划相同；仅相关子查询等特殊情况才明显更慢。
EXISTS 和 IN 怎么选？
存在性判断用 EXISTS；子查询结果集小且需返回列时用 IN。可空列避免 NOT IN。
子查询能替代 JOIN 吗？
部分可以，但需多表列输出或跨表聚合时，JOIN 不可替代，且通常更易被优化器处理。
本文更新于 2026 年 8 月，内容综合 SQLServerGuides、Dev.to、TechMixing、SQLabHub、CSDN 及腾讯 ima 知识库等公开技术资料整理。
