在关系型数据库中，把分散在不同表中的字段合并到一张结果集里，通常有两种写法：一种是在 SELECT 列表里嵌套多个子查询，另一种是用 JOIN 连接各表。虽然子查询写法直观，但数据量一大，执行效率往往迅速下降。本文从执行计划、改写场景和优化方法三个角度，说明为什么应该优先使用 JOIN，以及如何把多次子查询改写成高效的连接查询。
为什么多次子查询会拖慢多表合并
标量子查询最常见的形态，就是在 SELECT 的字段列表里直接嵌套查询。例如要查询订单表，同时带上用户名和部门名，不少人会写成两个独立的子查询。这种写法在数据量小的时候几乎感觉不到问题，可一旦 orders 表积累到几十万行，每个子查询都可能针对外层返回的每一行单独执行一次。即使连接字段上有索引，也会产生大量随机读和重复的索引查找，数据库的优化器往往会将这些子查询标记为 DEPENDENT SUBQUERY，意味着它必须等待外层行数据才能继续执行。
我们可以对比两种写法的执行计划。使用标量子查询时，orders 表每输出一行，就要分别去 users 表和 departments 表查一次，相当于把两个关联表的扫描次数放大到了主表行数的量级。而 JOIN 则完全不同，数据库只需要对 users 表和 departments 表各自做一次扫描或索引查找，再通过连接条件一次性匹配所有行。下面先给出子查询版本的典型代码：
SELECT
o.id,
o.order_no,
(SELECT u.username FROM users u WHERE u.id = o.user_id) AS username,
(SELECT d.dept_name FROM departments d WHERE d.id = o.dept_id) AS dept_name
FROM orders o
WHERE o.created_at >= '2024-01-01';
同样的需求换成 JOIN 后，逻辑并没有变复杂，但执行次数从主表行数乘以子查询个数，降到了固定次数。
SELECT
o.id,
o.order_no,
u.username,
d.dept_name
FROM orders o
LEFT JOIN users u ON u.id = o.user_id
LEFT JOIN departments d ON d.id = o.dept_id
WHERE o.created_at >= '2024-01-01';
还需要说明一点：部分数据库优化器确实可以把一些简单的标量子查询改写成 JOIN，但这种自动改写依赖查询复杂度和优化器版本，而且一旦子查询里包含聚合、排序或者条件分支，优化器很可能无法有效转换。显式使用 JOIN，能让自己对执行计划有更明确的掌控。
用JOIN改写子查询的常见场景与写法
除了字段列表中的标量子查询，IN 子查询也是多表合并时的性能重灾区。比如要查询有效作者发布的文章，开发者经常先查 authors 表拿到作者 ID 集合，再传给主查询的 IN 条件。这种写法看起来清晰，但 IN 里的子查询如果返回大量 ID，传递列表本身就会消耗内存和网络开销。改成 INNER JOIN 后，数据库可以直接在连接阶段完成过滤，只返回匹配的行。
-- 使用IN子查询 SELECT id, title FROM articles WHERE author_id IN (SELECT id FROM authors WHERE status = 1); -- 改写为JOIN SELECT a.id, a.title FROM articles a INNER JOIN authors au ON au.id = a.author_id WHERE au.status = 1;
多表合并时，LEFT JOIN 链是最常用的结构。但要注意，如果关联表之间存在一对多关系，JOIN 会导致主表行被放大。例如文章表关联评论表，一篇文章有多条评论，直接 JOIN 会输出重复的文章记录。此时如果业务只需要文章的基本信息，可以用 EXISTS 来代替 JOIN，或者在 SELECT 后加 DISTINCT。DISTINCT 会引入额外的排序或哈希去重，数据量大时反而不如 EXISTS 节省资源。
-- JOIN方式需要去重
SELECT DISTINCT a.id, a.title
FROM articles a
INNER JOIN comments c ON c.article_id = a.id
WHERE c.created_at >= '2024-01-01';
-- EXISTS方式天然避免重复
SELECT a.id, a.title
FROM articles a
WHERE EXISTS (
SELECT 1 FROM comments c
WHERE c.article_id = a.id
AND c.created_at >= '2024-01-01'
);
当需要合并的字段来自三张以上表时，建议把选择性最强的表作为驱动表，并确保每个 ON 条件都命中索引。LEFT JOIN 的连接顺序通常按照书写顺序从左到右，但优化器可能根据统计信息调整。如果中间某张表数据量庞大，可以把它放在靠后的位置，或者拆成多个子查询先聚合再 JOIN，避免笛卡尔积式放大。
高效合并多表字段的优化建议
JOIN 查询能不能快，索引是第一要素。所有参与 ON 条件的字段都应当建立索引，特别是被驱动表的关联字段。比如 users.id 和 departments.id 如果是主键，索引天然存在；但如果关联字段是 users.manager_id 这种普通列，就需要单独创建索引。此外，SELECT 后面尽量少用 *，只返回业务需要的字段，可以减少排序、回表和网络传输的开销。
判断一条多表合并查询是否高效，最直接的方法就是查看执行计划。以 MySQL 为例，可以在查询前加上 EXPLAIN。重点关注 type 列是否出现 ALL 或 index，这通常意味着全表扫描；还要看 rows 列估算扫描行数，以及 Extra 列是否出现 Using temporary、Using filesort。下面是一个简单的 EXPLAIN 示例：
EXPLAIN SELECT
o.id,
u.username,
d.dept_name
FROM orders o
LEFT JOIN users u ON u.id = o.user_id
LEFT JOIN departments d ON d.id = o.dept_id
WHERE o.status = 1;
如果执行计划显示 users 表的 type 为 eq_ref，说明连接条件命中了唯一索引；如果是 ref，说明命中了普通索引；如果出现 ALL，就需要检查连接字段是否有索引，或者索引是否失效。很多性能问题并不是 JOIN 本身引起的，而是缺少索引、关联字段类型不一致导致隐式转换、或者 OR 条件破坏了索引生效。
总结起来，用 JOIN 代替多次子查询的思路，核心在于减少重复扫描次数，让数据库一次性完成多表匹配。但 JOIN 也不是万能的，在只需要判断存在性、或者关联表有大量重复数据时，EXISTS 可能比 JOIN 更节省资源。实际开发中应当先分析数据分布，再用 EXPLAIN 验证执行计划，最终选择适合当前场景的写法。