在 SQL 编写过程中，常会遇到这样的抉择：此处应使用子查询还是 JOIN 查询？
“子查询是否真的性能较差？”
“JOIN 查询是否会带来更大的执行负担？”
本文将对两者的实现原理与性能差异进行系统梳理。
一、子查询与 JOIN 查询的基本概念
子查询（Subquery）
指在一个查询语句中嵌套另一个查询：
sql
SELECT *
FROM user
WHERE id IN (SELECT user_id FROM orders);
JOIN 查询（连接查询）
通过关联条件将多个表中的数据连接起来：
sql
SELECT u.*, o.*
FROM user u
JOIN orders o ON u.id = o.user_id;
二者虽皆可实现多表关联，但其底层执行机制有所不同。
二、性能差异核心结论
在多数中大型数据场景下，JOIN 查询通常表现更优，因此更受推荐。
主要原因在于：JOIN 允许数据库优化器对多表关联进行统一优化，而许多子查询（尤其是相关子查询）则难以获得同等程度的优化。
三、JOIN 查询性能优势的原因分析
1）JOIN 可充分利用优化器的重写与索引优化机制
JOIN 作为一种显式的表关联方式：
支持嵌套循环（Nested Loop Join）等连接算法
可明确区分驱动表与被驱动表
能够有效利用索引加速连接过程
优化器可灵活调整表连接顺序
支持谓词下推（WHERE pushdown）提前过滤数据
而子查询，尤其是相关子查询，往往无法实现上述优化。
2）JOIN 通常只需扫描必要数据，避免重复访问
以典型的相关子查询为例：
sql
SELECT name,
(SELECT COUNT(*) FROM orders o WHERE o.user_id = u.id) AS order_cnt
FROM user u;
若 users 表包含一万条记录，则该子查询将执行一万次，每次均需扫描 orders 表，极易引发重复计算与性能损耗。
而对应的 JOIN 查询则更为高效：
sql
SELECT u.name, COUNT(o.id)
FROM user u
LEFT JOIN orders o ON u.id = o.user_id
GROUP BY u.id;
此写法仅需对 orders 表进行一次扫描。
3）子查询可能引入临时表，增加额外开销
例如：
sql
SELECT * FROM orders
WHERE user_id IN (SELECT id FROM user WHERE status = 1);
此类查询可能导致数据库将子查询结果写入临时表（甚至磁盘临时表），从而带来额外的 I/O 与内存开销。
而 JOIN 查询则通常能直接通过索引完成过滤，无需中间临时结构：
sql
SELECT o.*
FROM orders o
JOIN user u ON o.user_id = u.id
WHERE u.status = 1;
四、子查询是否一定性能不佳？
并非绝对。自 MySQL 8.0 起，优化器已能将部分子查询自动重写为 JOIN 形式。
例如：
sql
SELECT *
FROM orders
WHERE user_id IN (SELECT id FROM user);
此类简单子查询可能被优化器转换为 JOIN 执行。
然而，以下情况仍难以优化：
相关子查询
包含聚合函数的子查询
子查询依赖外部查询列
子查询中包含 LIMIT、ORDER BY 等子句
结果集较大的 IN / NOT IN 子查询
使用 ANY/ALL/SOME 的子查询
在这些场景中，JOIN 仍具有明显的性能优势。
五、何时应优先选用 JOIN 查询？
数据量较大的表关联
业务逻辑较为复杂
需要基于多个关联字段进行过滤
子查询结果集规模较大
对性能有较高要求的业务场景（如订单处理、推荐系统、排行榜、日志分析等）
多数实际生产环境中的关联查询属于此类。
六、何时可考虑使用子查询？
子查询结果极小而稳定（如仅返回单行）
子查询与主查询无直接关联（非相关子查询）
子查询写法更直观，有利于代码可读性
仅需通过子查询进行过滤，而不希望因 JOIN 导致结果行数增加
简单的 IN 子查询（在支持优化的数据库版本中）
例如统计类查询：
sql
SELECT *
FROM orders
WHERE amount > (SELECT AVG(amount) FROM orders);
此类场景难以用 JOIN 直接替代。
七、总结
1. 子查询与 JOIN 的性能差异主要源于其执行机制的不同。
2. JOIN 通过连接算法、索引利用、驱动表选择等策略，通常能获得更优的执行效率。
3. 子查询，尤其是相关子查询，可能导致重复扫描、临时表创建等问题，影响性能。
4. 现代数据库如 MySQL 8.0 已对部分子查询进行优化，可自动转换为 JOIN，但仍非全覆盖。
实际开发建议：
多表关联优先采用 JOIN
尽量将相关子查询改写为 JOIN
仅在结果集小且 JOIN 不适用时保留子查询写法
来源：小程序app开发|ui设计|软件外包|IT技术服务公司-木风未来科技-成都木风未来科技有限公司
