MySQL优化三剑客：JOIN、子查询、UNION底层逻辑与实战调优

做了快十年的 MySQL 优化，我最大的体会是：大部分慢查询不是 SQL 写错了，而是写的人没想清楚数据到底是怎么流动的。今天要聊的这三剑客——JOIN、子查询、UNION，几乎覆盖了日常开发里百分之八十的查询需求，但很多人对它们的理解停留在“能用”层面，完全没意识到选型不同，性能可能差出几十倍。这篇文章我会把三者的底层执行逻辑、选型策略、常见坑位和实战调优过程一次讲透，适合刚入门想写好 SQL 的同学，也适合被慢查询折磨过、想系统梳理一遍的资深开发。

1. 三剑客的底层逻辑：先搞懂数据是怎么“碰”在一起的

1.1 从一次线上事故说起

前两年我接手过一个电商后台的报表接口，页面加载要十几秒，DBA 半夜把慢查询日志甩我脸上的时候，SQL 长这样：

sql复制SELECT ...
FROM orders o
WHERE o.user_id IN (
    SELECT user_id FROM vip_users WHERE level > 3
)
UNION
SELECT ...
FROM refunds r
WHERE r.user_id IN (
    SELECT user_id FROM vip_users WHERE level > 3
);

这条 SQL 逻辑上一点毛病没有：查高等级会员的订单和退款记录，去重合并。但线上跑起来就是慢，原因藏在三个词里：IN 子查询的重复执行、UNION 的去重排序、以及两张表各自扫描造成的大量随机 IO。当时我第一反应不是改 SQL，而是先看执行计划。看完之后发现，优化器把 IN 子查询转成了半连接，但驱动顺序完全错了，大表 orders 反而成了驱动表，小表 vip_users 被反复访问。

那次事故之后，我养成了个习惯：任何涉及 JOIN、子查询、UNION 的 SQL，先问三个问题——数据量级是多少？连接列有没有索引？去重是否真的必要？这三个问题想清楚，性能问题基本能解决一大半。

1.2 JOIN 的本质是组合，子查询的本质是分步，UNION 的本质是堆叠

很多文章喜欢从语法层面讲三者的区别，但我觉得从数据流动方式理解更直观。

JOIN 是“横向组合”。它把两张表的行按连接条件拼在一起，结果集的列是两张表的列相加，行数是匹配逻辑决定的。它解决的是“一张表的信息不够用”的问题。比如订单表只有 user_id，你需要用户姓名，就得把用户表 JOIN 进来。

子查询是“分步计算”。它把一个复杂问题拆成“先算 A，再基于 A 算 B”。逻辑上它天然适合表达层次关系，比如“找出买了最热门商品的那批用户”。但正因为它是分步的，如果优化器没做好转换，每一步都可能成为独立的执行单元，性能就悬了。

UNION 是“纵向堆叠”。它把多个查询的结果按行拼在一起，要求每个 SELECT 的列数、列顺序、数据类型兼容。它解决的是“同一类数据分散在多张表/多个条件里，需要合并展示”的问题。比如查询订单和退款记录，两者结构相似，就要 UNION。

理解了这个底层区别，选型就迈出了第一步：先看你要解决的问题是缺列、缺步骤，还是缺行。 缺列用 JOIN，缺步骤用子查询，缺行用 UNION。这个判断标准我记了快十年，几乎没出过错。

1.3 选型框架：没有万能银弹，只有场景匹配

很多人喜欢问“JOIN 和子查询哪个快”，这问题本身就问错了。脱离场景谈性能就是耍流氓。

给你一个我常用的决策顺序：

1. 先看数据量级。小表（几千行以内）随便写，优化器能处理。大表（百万行以上）才需要认真选型。
2. 再看连接/筛选列是否有索引。没索引，JOIN 和子查询都好不到哪去。
3. 然后看业务逻辑的复杂度。逻辑嵌套超过三层，优先考虑拆成临时表或 WITH AS，别为难优化器。
4. 最后看结果集是否需要去重。需要去重才用 UNION，否则一律 UNION ALL。

这个框架不是银弹，但它能帮你在写 SQL 的时候形成条件反射。下面我分三章把每个操作讲透。

2. JOIN：组合的艺术与驱动表陷阱

2.1 驱动表与被驱动表：谁先谁后有讲究

JOIN 性能的核心秘密是嵌套循环连接（Nested Loop Join）。优化器会选一张表作为驱动表（外表），遍历它的每一行，再去被驱动表（内表）里找匹配行。这个过程中，被驱动表会被访问多少次，取决于驱动表返回多少行。

举个例子：

sql复制SELECT *
FROM users u
JOIN orders o ON u.id = o.user_id
WHERE u.level > 3;

如果 users 表经过 level > 3 过滤后返回 1000 行，那么 orders 表理论上会被查找 1000 次。如果反过来，orders 表先被过滤出 10 万行，那 users 表也要被访问 10 万次。结果可想而知。

所以 MySQL 里有一个经典原则：小表驱动大表。但要注意，这里的“小”不是指表的物理大小，而是“经过 WHERE 过滤后参与连接的行数”。优化器通常会选择行数少的作为驱动表，但统计信息不准、或者索引缺失时，它会选错。

怎么判断谁被驱动了？看 EXPLAIN 的第一行就是驱动表，后面跟着的是被驱动表。我经常看到有人抱怨“我很简单的 JOIN 怎么这么慢”，一查执行计划，第一行是个返回几万行的派生表，后面跟着的却是应该只返回几百行的主表，这明显选反了。

这时候不要急着用 STRAIGHT_JOIN 强制指定顺序，先检查统计信息是否更新了，再确认连接列索引是不是被函数或隐式转换破坏了。强制指定是最后手段，我一般只在优化器反复犯傻时才用。

2.2 为什么大厂不建议多表 JOIN

网上流传一个说法：“大厂禁止三张表以上的 JOIN”。我第一次听到也觉得夸张，后来在几个不同规模的项目里都验证了，这话有它的道理，但很多人理解偏了。

大厂真正怕的不是 JOIN 本身，而是无索引的 JOIN、笛卡尔积风险的 JOIN、以及连接列类型不一致导致的隐式转换。更根本的，是 JOIN 一旦涉及多张表，优化器评估执行计划的成本会成倍增长，统计信息稍微不准，执行计划就可能跑偏。数据量大到一定级别后，JOIN 还可能拖垮 Buffer Pool，导致其他查询受影响。

但这不代表业务里不能 JOIN。我的经验是：两张表 JOIN，索引合理，通常是没问题的；三张以上就要仔细掂量了。如果一定要多表 JOIN，优先保证连接列都有索引，并且每张表提前做条件过滤，尽量减少参与连接的行数。

还有一种情况是大表 JOIN 大表，这时候别说三张，两张都危险。更好的方案是把 JOIN 拆成多次查询，在应用层做数据组装。虽然网络开销增加了，但数据库的压力会被打散，整体稳定性更好。尤其在高并发场景下，宁可多几次快速查询，也不要一次长时间占用连接。

2.3 JOIN 索引三板斧：连接列、覆盖索引、小表驱动大表

JOIN 索引设计其实不复杂，核心就三件事：

第一，连接列必须有索引。 JOIN 的被驱动表连接列上如果没有索引，MySQL 就只能对这张表做全表扫描，这个代价是灾难性的。连接列索引最常用的是 B+ Tree 索引，如果连接列是字符串且区分度低，可以考虑前缀索引，比如 INDEX (user_code(20))。

第二，关注覆盖索引。 如果一个查询只需要某几个列，尽量让这几个列都在索引里，MySQL 就能直接用索引覆盖，不用回表。比如 SELECT u.name, o.amount FROM users u JOIN orders o ON ...，如果 orders 表有 (user_id, amount) 联合索引，amount 就可以直接从索引取，省一次回表。

第三，小表驱动大表要配合 WHERE 条件。 不要指望着优化器永远聪明。在写 SQL 的时候，就把过滤条件放在正确的位置，让每张表进 JOIN 之前尽量瘦身。

给你看一个我常用的排查习惯：拿到一条慢 JOIN，先 EXPLAIN 看每一行的 type 字段。如果出现 ALL，就说明有一张表在全表扫描；如果出现 Using join buffer，说明连接列没有索引。这两个信号基本能定位 90% 的 JOIN 性能问题。

3. 子查询：从性能杀手到 WITH AS 临时表

3.1 相关子查询为什么慢

子查询分两种：非相关子查询（独立子查询）和相关子查询（相关子查询）。

非相关子查询可以独立执行一次，结果作为外层查询的输入，性能通常可控。比如：

sql复制SELECT * FROM orders
WHERE user_id IN (SELECT id FROM users WHERE level = 1);

这个子查询不依赖外层查询的任何列，MySQL 可以先算出子查询结果，再拿它去过滤 orders。

相关子查询就麻烦了，它里面的条件用到了外层查询的列，比如：

sql复制SELECT * FROM orders o
WHERE o.amount > (
    SELECT AVG(amount) FROM orders o2 WHERE o2.user_id = o.user_id
);

这个查询对 orders 表的每一行，都要执行一次子查询！如果 orders 有 100 万行，子查询就要跑 100 万次。即使单次子查询只要 1 毫秒，总耗时也是 1000 秒。这就是相关子查询被称为“性能杀手”的原因。

我见过不少新手写了相关子查询还浑然不觉，看到 EXPLAIN 里 DEPENDENT SUBQUERY 才恍然大悟。遇到这种关键字，一定要警惕：要么改写，要么确认外层行数真的非常少。

3.2 IN/EXISTS/半连接转换：优化器帮你做了什么

MySQL 优化器没那么笨。对于 IN (子查询)，它会尝试把子查询转换成半连接（Semi-join），也就是“只要存在匹配就返回”，不需要一一配对。半连接有几种实现方式：

• Duplicate Weedout：去重后匹配
• First Match：找到第一条匹配就停止
• Loose Scan：利用索引跳过不必要的数据
• Materialization：把子查询结果物化成临时表再连接

哪个效果好，取决于数据分布和索引。普通开发者不需要精读执行计划的每一步，但要知道一件事：IN 子查询在现代 MySQL 里已经没你想象的那么可怕，EXISTS 也未必更优。

以前大家会说“IN 适合子查询结果集小的情况，EXISTS 适合外层表小的情况”，这在 5.6 之前有参考价值，现在优化器会做转换，你只要保证子查询和外表连接列有索引，剩下的交给优化器。

真正要避免的是把 IN 写成超大列表，比如 IN (10000个值)。这种情况下优化器也没辙，建议拆成临时表 JOIN，或者分批处理。

3.3 WITH AS 临时表：让优化器看清你的意图

MySQL 8.0 开始支持 CTE（Common Table Expression），也就是 WITH AS。它的最大价值不是性能提升，而是让复杂查询的结构清晰可读，同时可以多次引用同一结果。

sql复制WITH vip_users AS (
    SELECT id FROM users WHERE level > 3
)
SELECT ... FROM orders o JOIN vip_users v ON o.user_id = v.id;

很多人以为 CTE 一定比子查询快，其实不一定。CTE 在某些情况下会被物化成临时表，物化是有成本的。但它有两个明显好处：

第一，复杂查询可读性大幅提升，维护成本降低。第二，同一个 CTE 被多次引用时，优化器有机会只物化一次，而不是重复执行子查询。

我之前接手一个报表 SQL，光子查询就嵌套了五层，改写成三个 CTE 之后，不仅性能提升了，DBA 和同事都能看懂了。运维人最怕的不是性能差，而是看不懂，改都不敢改。

说到临时表，还有一个场景值得提：如果你的子查询结果集很小（比如几百行），MySQL 可能会自动物化成临时表，并为它加索引。这时性能反而好。但如果结果集特别大，物化临时表本身就会成为瓶颈。判断方法还是看执行计划里有没有 Materialize 关键字。

4. UNION 与 UNION ALL：去重不要想当然

4.1 UNION 和 UNION ALL 的本质区别：临时表 + 排序去重

很多初学者只知道“UNION 会去重，UNION ALL 不去重”，但对性能影响没概念。

UNION 的执行流程是这样的：先把多个 SELECT 的结果合并，写入一个临时表，然后对临时表做唯一性检查。这个检查通常伴随着排序或哈希操作。如果结果集有几百万行，排序去重的代价非常可观。

UNION ALL 就简单得多，它直接把所有结果堆叠返回，完全不去重。所以性能上，UNION ALL 永远优于 UNION，这一点没有例外。

那什么时候用 UNION？只有一个场景：业务上必须保证结果集的行唯一，而且你确认不去重就会有脏数据。 如果两个查询的结果本身就不可能重复，比如一个是昨天的数据，一个是今天的数据，用 UNION ALL 就行，千万别手滑写成 UNION。

我见过太多慢查询，就是 UNION 去重造成的。明明数据源已经保证不重复了，偏要用 UNION，白白多一次排序。省下的那点去重时间，在高并发下可能就是接口响应从 200ms 变 2s 的差距。

4.2 Illegal mix of collations 的坑

做 UNION 时经常会碰到一个经典报错：

code复制Illegal mix of collations (utf8mb4_general_ci,IMPLICIT) and (utf8mb4_0900_ai_ci,IMPLICIT) for operation 'UNION'

出现这个报错，是因为两个 SELECT 出来的相同列，字符集排序规则不一致。MySQL 在合并时会要求两侧的 collation 兼容，不然它不知道按谁的规则来比较。

这个问题的根源很常见：不同表建表时用了不同的字符集默认规则。比如 MySQL 5.7 默认 utf8mb4_general_ci，MySQL 8.0 默认 utf8mb4_0900_ai_ci，两库一同步，UNION 直接报错。

解决办法有几种：

1. 在列上强制指定 collation：SELECT name COLLATE utf8mb4_general_ci FROM table_a UNION SELECT name FROM table_b
2. 先把列转成相同字符集：CONVERT(name USING utf8mb4)
3. 统一建表规范，让所有相关表使用相同的字符集和排序规则。这个才是治本之法。

我自己的习惯是在项目初始化时就把字符集统一为 utf8mb4 和 utf8mb4_general_ci，并写进数据库规范文档。虽然 utf8mb4_0900_ai_ci 更符合现代 Unicode 标准，但只要团队里有人从 5.7 迁移上来，混用就是隐患。

4.3 什么时候该拆查询，什么时候该用 UNION

UNION 并不是唯一的合并方案。在某些场景下，拆成多个查询在应用层合并，反而性能更好。

最简单判断标准：看两个结果集之间有没有交集，以及合并之后要做什么。

如果你需要分页，比如“把订单和退款合并，按时间排序，取第 20 到 30 条”，在 MySQL 里直接用 UNION 子查询再 LIMIT 可能没问题，但如果数据量巨大，UNION 先合并再去排序分页，会先算出全量结果，代价极高。这时候更好的做法是分别在两条查询里做分页，应用层再合并。

另外要注意，UNION 对列名和数据类型是有要求的。第一个 SELECT 的列名会被用作最终结果的列名，后续 SELECT 的列名会被忽略。数据类型不一致时，MySQL 会做隐式转换，可能导致索引失效。比如一边是字符串，一边是整数，排序规则就乱了。

分享一个我实践过多次的优化思路：如果两个分支查询有共同的 WHERE 条件，比如都要求 status = 1，这个条件要在每个分支里都写，而不是等 UNION 完再过滤。因为 MySQL 不会智能地把外层 WHERE 下推到每个 UNION 分支，你不写，它就白算一批数据。

5. 实战：一个销售报表的查询优化全记录

5.1 原始查询：三层嵌套子查询 + UNION

前面铺垫了那么多，来一个完整的实战案例。这是一个销售报表，需求是：查出最近 30 天内，高级会员的下单金额 TOP 20，以及高级会员的退款金额 TOP 20，合并展示，按金额倒序，取前 20。

原始 SQL 大概是这样的：

sql复制SELECT user_id, amount, 'order' AS biz_type
FROM orders
WHERE user_id IN (SELECT id FROM users WHERE level > 3)
  AND order_time >= NOW() - INTERVAL 30 DAY
ORDER BY amount DESC
LIMIT 20

UNION

SELECT user_id, amount, 'refund' AS biz_type
FROM refunds
WHERE user_id IN (SELECT id FROM users WHERE level > 3)
  AND refund_time >= NOW() - INTERVAL 30 DAY
ORDER BY amount DESC
LIMIT 20

ORDER BY amount DESC
LIMIT 20;

这个 SQL 至少有四个问题：

1. 每个分支里的子查询都执行一遍 SELECT id FROM users WHERE level > 3，重复劳动。
2. UNION 会对合并结果去重排序，但这里 biz_type 字段保证了行必不重复，去重完全没必要。
3. 每个分支里的 ORDER BY ... LIMIT 20 在 UNION 里根本不起作用，只会增加计算负担。
4. 子查询 users 如果没有走索引，orders 表扫描的每一行都要回查一次。

5.2 执行计划解读：哪里是瓶颈

我在原表上 EXPLAIN 了一下，几个关键信息如下：

• 第一个分支的子查询类型是 DEPENDENT SUBQUERY，虽然优化器可能做了转换，但 users 表返回的行数较多时，明显影响速度。
• orders 表的 type 是 ALL，说明连接时做了全表扫描。
• refands 表的情况类似。

说白了，真正慢的原因是：子查询没走索引 + 全表扫描 + 多余的排序去重。这三个问题叠加，报表接口自然是秒级响应。

5.3 优化后的 SQL 与对比

我做的第一步是把公用的“高级会员 ID”抽出来作为 CTE，第二步把 UNION 改成 UNION ALL，第三步把分支里的 ORDER BY LIMIT 删掉，最后一步在应用层做最终排序和分页。

优化后的 SQL 大概是这样的：

sql复制WITH vip_users AS (
    SELECT id FROM users WHERE level > 3
)
SELECT user_id, amount, 'order' AS biz_type
FROM orders o
JOIN vip_users v ON o.user_id = v.id
WHERE o.order_time >= NOW() - INTERVAL 30 DAY

UNION ALL

SELECT user_id, amount, 'refund' AS biz_type
FROM refunds r
JOIN vip_users v ON r.user_id = v.id
WHERE r.refund_time >= NOW() - INTERVAL 30 DAY

ORDER BY amount DESC
LIMIT 20;

这里有个细节：我把 ORDER BY 和 LIMIT 只放在最终结果上，而不是每个分支里。因为 UNION 的语义决定了，分支里的排序和分页在合并时没有意义，只写一次反而清晰。

实测下来，查询时间从原来的 8 秒降到了 0.3 秒左右。提升的关键是：

1. CTE 让 vip_users 只物化一次，避免了重复子查询。
2. JOIN 代替 IN 子查询，配合 users 表主键索引，连接效率大幅提升。
3. UNION ALL 省掉了去重排序。
4. 去掉了无意义的中间排序。

5.4 一个值得注意的排序坑

优化后的 SQL 还有一个小问题：最终 ORDER BY amount DESC LIMIT 20 是在 UNION ALL 结果集上做的，MySQL 必须先把两个分支的结果全部取出，才能排序取前 20。如果两个分支各自返回几十万行，这条 SQL 依然会有大量临时表操作。

更极致的做法是：让每个分支各自按 amount 取前 20，然后在应用层把这 40 条合并后排序取前 20。因为最终 TOP 20 必然来自两个分支各自 TOP 20 的交集。这是典型的“剪枝”思想。

这个优化我通常会在数据量超过百万级时才做，因为它牺牲了一定的通用性，需要改代码。但收益非常明显，接口响应可以再降一个量级。有兴趣的话可以自己试一下，拿实际数据对比，感受会很直观。

6. 常见问题与排查技巧实录

6.1 快查表

这里整理一份我日常工作里最常用的问题快查表，遇到类似情况可以直接对照：

6.2 我踩过的几个坑

第一个坑：隐式类型转换。 连接列一边是 VARCHAR 存数字，一边是 INT，MySQL 会把 VARCHAR 转成数字比较，但索引可能就失效了。有一次我排查了半天，加了索引还是慢，最后发现是用户表 id 存成了字符串，订单表 user_id 是 INT，JOIN 一走函数就炸了。

第二个坑：统计信息不准导致执行计划跑偏。 MySQL 的优化器依赖统计信息选择驱动表和索引，如果某张表数据量剧烈变化，但 ANALYZE TABLE 没跑，执行计划可能还停留在旧状态。我养成了在数据批量导入后、或者每月定时任务里 ANALYZE TABLE 的习惯，小动作解决大问题。

第三个坑：看到慢查询就急着改 SQL，没先看数据分布。 有些慢查询其实是业务该加缓存，或者该做数据归档。比如订单表堆了三年历史数据，怎么优化 SQL 都解决不了根上的问题。还是那句话，先搞清数据量级和分布，再动手。

第四个坑：误把查询优化等同于加索引。 索引不是越多越好，一个表超过五六个索引，写入性能会明显下降。我见过有人为了一个查询建了三个索引，最后发现联合索引能覆盖两个查询，删掉了一个冗余索引，性能反而更稳定。

6.3 一点心得：执行计划是最好的老师

最后说点掏心窝的话。我见过太多人遇到慢查询就上网搜“MySQL 优化”，然后复制一堆不理解的配置参数改一遍。其实排查慢查询最有效的路径永远是固定的：

1. 拿到慢查询日志，确认是哪条 SQL。
2. 看这条 SQL 的执行计划，找到全表扫描或临时表排序的位置。
3. 针对瓶颈点分析，是索引问题、连接顺序问题，还是业务需要改写法。
4. 改完再 EXPLAIN，对比 cost 和 rows 的变化，确认是否真的有效。

这套流程走熟了，JOIN、子查询、UNION 这些操作根本不需要背什么“武功秘籍”。你需要的不是一条万能优化法则，而是理解 MySQL 背后是怎么执行的。优化器的执行逻辑就是：能走索引就走索引，能少算就少算，能不去重就不去重。你顺着它的思路写 SQL，它就会回报你飞快的响应速度。

我后来带团队时，要求每个人写完复杂 SQL 必须贴出 EXPLAIN 结果，跑批脚本上线前要做 SQL Review。看起来流程重了，但真的能省掉未来无数的深夜告警。写 SQL 这事儿，慢就是快，稳就是快。