子查询与 JOIN 查询性能比较：执行机制与适用场景解析

在 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 执行。

然而，以下情况仍难以优化：