MySQL子查询真不能用吗？从执行计划看子查询与JOIN的真相-代码聚汇网

MySQL子查询真不能用吗？从执行计划看子查询与JOIN的真相

MySQL子查询JOIN

|难度：普通|阅读约 40 分钟

开篇那种“面试必问：MySQL为什么不用子查询”的问题，这几年我听了无数遍。每次都有一种很复杂的感受：问的人可能是真的在面试题里见过，答的人也往往背得很熟——“因为子查询性能差，要用JOIN代替”。但这个回答放到MySQL 8.0的生产环境里，很多时候是错的。我自己就处理过不少线上慢查询，有些SQL拿着子查询跑得好好的，改成JOIN之后反而更慢，还有的直接改出了结果集膨胀的故障。所以今天想认真聊一聊：这句话到底从哪来，它背后的原理是什么，在什么场景下成立、在什么场景下已经过时。如果你是刚接触MySQL的开发者，或者准备面试正在背结论，又或者已经在生产环境被子查询坑过，这篇文章会告诉你一个更完整的判断方法。

1. 为什么“别用子查询”会变成流传多年的祖训

1.1 一条经验从MySQL 5.1时代开始流传

很多年轻开发者可能不知道，中文互联网上大量关于MySQL的“祖训”，源头可以追溯到MySQL 5.1、5.5时代。那时候的MySQL优化器远没有今天这么智能，子查询的处理方式也确实相当粗暴。当年流行的技术博客、纸质书、论坛帖子里，大量DBA和数据开发都在反复强调一个结论：别写子查询，用JOIN代替。

这个结论在当时是真实有效的。MySQL 5.1时代的优化器对子查询的执行能力很弱，尤其是IN子查询，很多时候并不会先执行内层子查询得到结果集，再与外表做匹配，而是会被重写成EXISTS相关的执行方式。也就是说，表面上你写的是一个先子查询后匹配的逻辑，数据库底层实际做的却是“逐行执行内层查询”。

问题是，那个年代没有几个人会去看EXPLAIN，也很少有开发能读懂DEPENDENT SUBQUERY意味着什么。于是“不要使用子查询”这一条，就以经验的形式一级一级传了下来。等到MySQL 5.6、5.7、8.0陆续完善了子查询的优化能力，这句经验已经变成了一种默认的“最佳实践”，很少有人去质疑它在新版本下是否还成立。

1.2 老版本优化器的执行模型缺陷

我们来看老版本优化器处理IN子查询时的典型操作。假设有这样一个查询：

sql复制SELECT *
FROM customers
WHERE id IN (SELECT customer_id FROM orders WHERE status = 1);

在MySQL 5.5及之前，如果orders表上的status列没有合适的索引，或者优化器认为内层结果集太大不适合直接物化，它在很多场景下会把语句改写成类似这样的相关子查询：

sql复制SELECT c.*
FROM customers c
WHERE EXISTS (
    SELECT 1
    FROM orders o
    WHERE o.customer_id = c.id
      AND o.status = 1
);

注意，这里的o.customer_id = c.id是一个关联条件，内层查询依赖外层当前行的c.id。于是整个执行过程就变成了：扫描customers表，取出第一行，用这一行的id值去orders表里查一次；再取第二行，再查一次……如果customers表有10万行，内层查询就要被执行10万次。

这种执行方式在MySQL源码里就是典型的“相关子查询逐行执行”，EXPLAIN输出里对应DEPENDENT SUBQUERY。更要命的是，如果内层查询里的orders.customer_id没有索引，那每查处一行都要做一次全表扫描，10万次全表扫描的代价可想而知。

很多老DBA口中“子查询慢到让人崩溃”的案例，本质都是这个执行模型造成的。

1.3 一条慢查询把“祖训”刻进了团队规范

我记得早年在团队里接手过一个线上问题。业务方反馈一个统计接口超时严重，每次请求要跑二十几秒。把SQL捞出来一看，就是一个典型的带IN的子查询：外层是一张几百万行的用户流水表，内层是一个分组统计后返回用户ID的结果集，当时那套业务跑在MySQL 5.5上。

由于公司数据库版本偏老，这个子查询实际执行时走了相关子查询路线，外层扫描到多少行，内层就重复执行多少次。最终的结果就是CPU打满、慢查询日志刷屏。我当时的第一反应也是“把子查询改成JOIN”，改完以后确实快了不少，从此团队里就立了一条规矩：所有新SQL不允许写子查询。

现在回头看，那条规矩立得太绝对了。当时的正确解法应该是先分析为什么优化器选择了相关子查询，是版本太老、缺索引还是统计信息不准？但那个年代的运维压力摆在那里，没有人有精力把每一个慢查询都研究透，最快能止血的方案就是禁用子查询。于是这一条“不用子查询”的经验从一个团队传到另一个团队，最终变成了大量面试题的标准答案。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 子查询到底慢在哪：一个执行计划的解剖

2.1 相关子查询：外层扫多少行，内层就执行多少次

要判断一个子查询是不是潜在的性能隐患，首先得区分它是“相关子查询”还是“非相关子查询”。

非相关子查询的执行方式比较直接，比如：

sql复制SELECT *
FROM customers
WHERE id IN (SELECT customer_id FROM orders WHERE order_time > '2024-01-01');

如果优化器选择先把内层查询跑完，结果放临时表，再用临时表和外表做连接，那么内层查询只会执行一次。这种策略叫物化或半连接物化，整体代价可控。

相关子查询则不同，内层查询里包含了对外层表列的引用。典型写法是：

sql复制SELECT c.*
FROM customers c
WHERE EXISTS (
    SELECT 1
    FROM orders o
    WHERE o.customer_id = c.id
      AND o.order_time > '2024-01-01'
);

这里的c.id来自外层，优化器如果不能把它转换为半连接，就只能采用“外表驱动、逐行探测”的方式。外层返回多少行，内层就执行多少次查询。不管这个内层查询的索引建得多好，当外层行数达到百万级时，百万次索引查找累积起来的开销也会非常可观。

用生活里的例子类比，这就好比你有一张购物清单，每拿出一个商品，都要跑到仓库里重新翻一遍货架去找对应位置。仓库虽然整理得不错，找一次只要几秒钟，但你清单上有几千个商品，每找一个商品就上一次楼，时间和体力的消耗自然会翻倍。

2.2 派生表又物化又没索引时的双重成本

除了WHERE条件里的子查询，FROM子句里的派生表也是一种常见的写法。比如：

sql复制SELECT c.name, t.total_amount
FROM customers c
JOIN (
    SELECT customer_id, SUM(amount) AS total_amount
    FROM orders
    WHERE order_time >= '2024-01-01'
    GROUP BY customer_id
) t ON t.customer_id = c.id;

在MySQL 5.6之前，这类派生表几乎都是先物化成一张临时表再参与JOIN。如果内层结果集很大，MySQL只能把临时表写到磁盘上；更麻烦的是，早期的物化临时表默认不建索引，后续与customers表JOIN时，对临时表只能做全表扫描。

这个问题直到MySQL 5.7引入了Derived Condition Pushdown和派生表合并优化，才得到明显改善。8.0版本对派生表的处理能力已经强很多，但如果派生表里有GROUP BY、DISTINCT、聚合函数、LIMIT、UNION等复杂子句，优化器依然无法把派生表合并到外层，只能老老实实物化。

这就解释了为什么网络上很多“子查询不能用于FROM”的劝退文章至今仍然有一定道理——他们的测试可能建立在5.6或5.7的早期版本上，并且使用了一个无法被合并的复杂派生表。但在8.0里遇到一些简单的派生表时，优化器完全可以把内层SQL“展开”后与外层合并，实际执行计划里根本看不到任何物化过程。

2.3 EXPLAIN里的这几个词，就是危险信号

很多开发看到EXPLAIN输出中一长串的type、key、rows就头疼。但实际上你只需要关注几个关键词，就能判断当前子查询的执行方式是否健康：

EXPLAIN输出关键词	含义	是否需要警惕
DEPENDENT SUBQUERY	子查询是相关子查询，可能逐行执行	高
UNCACHEABLE SUBQUERY	子查询无法缓存结果，每次都要重新执行	高
MATERIALIZED	子查询结果被物化成临时表	中，看数据量
DERIVED	FROM子句中的派生表被物化	中，看数据量
PRIMARY	外层主查询	正常

如果在执行计划里看到DEPENDENT SUBQUERY或UNCACHEABLE SUBQUERY，而且外层表的预估行数非常大，基本可以断定这个查询的影子下藏着一个“逐行执行”的循环。此时无论内层查询走不走索引，性能大概率不会好到哪里去。

反过来，如果你在8.0版本中执行一条IN子查询，看到执行计划里出现的是Materialize或者FirstMatch这样的半连接策略，那说明优化器已经把子查询优化得非常好了，完全没必要手工改成JOIN。

2.4 “Not In 返回空”的经典语义陷阱

关于子查询，还有一个和性能无关但同样致命的问题，就是NULL值带来的语义陷阱。我见过不止一个同事在排查数据问题时，发现某条SQL“查不到数据”，排查半天以为是权限或索引问题，最后才发现是NOT IN踩了NULL的坑。

考虑下面这种写法：

sql复制SELECT *
FROM customers
WHERE id NOT IN (
    SELECT customer_id
    FROM blacklist
);

如果blacklist表中有一行的customer_id是NULL，那么整个查询的结果集会变成空。原因也很简单：id NOT IN (1, 2, NULL)的逻辑是“id不等于1 且 id不等于2 且 id不等于NULL”，而“id不等于NULL”这个条件永远不会成立——任何值与NULL做比较的结果都是UNKNOWN，WHERE只保留结果为TRUE的行。

这个问题在很多老博客里通常会和子查询性能一起提，但它们其实是两个维度的问题。一个是执行计划的性能缺陷，一个是SQL语义上的理解错误。可恰恰因为这层关系，“不要用NOT IN子查询”也成了很多团队规范里的硬杠杠。

3. 实测对比：IN子查询、EXISTS与JOIN的真实表现

3.1 测试环境与造数口径

理论说了这么多，我用一个简化过的业务模型实际对比一下。测试是在MySQL 8.0.28上做的，两张表分别模拟“用户表”和“订单表”。

sql复制CREATE TABLE customers (
    id INT PRIMARY KEY,
    name VARCHAR(50) NOT NULL,
    region VARCHAR(20) NOT NULL,
    created_at DATETIME NOT NULL
);

CREATE TABLE orders (
    id INT PRIMARY KEY,
    customer_id INT NOT NULL,
    amount DECIMAL(10,2) NOT NULL,
    status TINYINT NOT NULL,
    order_time DATETIME NOT NULL,
    KEY idx_customer_id (customer_id),
    KEY idx_status (status)
) PARTITION BY HASH(id) PARTITIONS 4;

我往customers表里插入了20万行，往orders表里插入了800万行，status=1的订单大约占30%。这个量级不算夸张，但在真实OLTP业务里已经能看出明显的执行计划差异了。

需要先说明一点：不同机器、不同数据分布下跑出来的耗时一定会有差异，下面的对比重点不是具体数字，而是执行计划的形态差异和优化器对写法的敏感度。

3.2 IN子查询与JOIN：现代版本下差距并没有想象中大

第一个测试是查出所有下过有效订单的用户：

sql复制-- 写法A：IN子查询
SELECT *
FROM customers
WHERE id IN (
    SELECT customer_id
    FROM orders
    WHERE status = 1
);

-- 写法B：JOIN后去重
SELECT DISTINCT c.*
FROM customers c
JOIN orders o ON o.customer_id = c.id
WHERE o.status = 1;

在上面这个数据形态下，执行计划显示写法A已经被优化器转换成半连接，具体策略是Materialize加Nested loop。优化器先把orders表中符合status=1条件的customer_id物化到临时表里，顺便去掉了重复值，然后与customers表做连接。由于临时表只包含一个整型字段且数据量不过百万级，这个物化过程非常轻量。

写法B同样效率不差，但注意它多了DISTINCT。MySQL需要对最终结果做去重排序，如果JOIN过程中同一个用户匹配了多条订单，结果集膨胀明显时，DISTINCT可能会引入额外的临时表和排序操作。

所以在这组对比里，IN子查询并没有输给JOIN。甚至在某些数据分布下，IN子查询的表现更好——因为优化器做半连接时明确知道只需要判断是否存在，可以提前结束内层循环。而手工JOIN，如果忘记加DISTINCT，还会直接产生错误的结果集。多年前我处理过的真实故障中，就有人把子查询“优化”成JOIN后，同一条订单被重复统计了三次，最后报表数字怎么都对不上。

3.3 EXISTS相关子查询的索引依赖

第二个测试换成EXISTS：

sql复制SELECT *
FROM customers c
WHERE EXISTS (
    SELECT 1
    FROM orders o
    WHERE o.customer_id = c.id
      AND o.status = 1
);

在8.0里执行这条SQL，EXPLAIN的结果通常会显示它一样被转换成了半连接。内层表orders选择idx_customer_id索引进行查找，整体执行策略依然是先访问customers表，再用每一行的id去orders表里探测。表面上看它仍然是相关执行，但每一次探测都走的是二级索引，成本很低。

这里的关键在于：必须以orders.customer_id作为驱动条件，并且该列上有合适的索引。如果把条件反过来，例如写成：

sql复制SELECT *
FROM customers c
WHERE EXISTS (
    SELECT 1
    FROM orders o
    WHERE o.status = 1
      AND o.customer_id = c.id
);

在数据分布合理、优化器能正确估算的情况下，两条SQL的执行计划是等价的，索引依然会被使用。但如果你在status列上没有索引，而优化器又无法把条件推入子查询，那效率就完全不一样了。

在我的测试里，EXISTS写法和IN写法的执行时间基本处于同一个数量级，差距不超过10%。当外层表数据量只有几百行时，两者的差异甚至可以忽略不计。

3.4 NOT IN、NOT EXISTS与LEFT JOIN反连接

第三组测试是反连接，也就是“查出没有下过有效订单的用户”：

sql复制-- 写法C：NOT IN
SELECT *
FROM customers
WHERE id NOT IN (
    SELECT customer_id
    FROM orders
    WHERE status = 1
);

-- 写法D：NOT EXISTS
SELECT *
FROM customers c
WHERE NOT EXISTS (
    SELECT 1
    FROM orders o
    WHERE o.customer_id = c.id
      AND o.status = 1
);

-- 写法E：LEFT JOIN反连接
SELECT c.*
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.id AND o.status = 1
WHERE o.id IS NULL;

在没有NULL干扰的前提下，三条SQL执行后的数据结果是一致的。但执行计划有些差异。

NOT IN在8.0中通常会被识别为Anti join，优化器使用反连接方式处理，效率并不低。可一旦子查询结果中出现NULL，NOT IN的数据结果就会出错，这是它的语义弱点。

NOT EXISTS和LEFT JOIN...IS NULL两种写法在MySQL里通常都会被优化成Anti join，实际执行方式非常接近。区别在于，LEFT JOIN写法要求我们想清楚关联条件里要不要把status = 1放进ON子句，一旦条件位置放错，结果就可能完全不对。

如果orders表极大，而customers表较小，通常推荐用NOT EXISTS。优化器会以customers为驱动表，对每个用户去orders表里做索引探测，整个过程高效且语义直观。这三条SQL的性能差异在数据量小时基本看不出来，真正拉开差距的是内层表非常大、外层表也不小、且索引设计不合理的时候。

4. 真要改写时，我的具体步骤与验证方法

4.1 第一步永远是打开执行计划

处理线上慢查询时，我会控制住自己“立刻把子查询改成JOIN”的冲动。第一步永远是先跑一次EXPLAIN，看看执行计划里到底出现了什么信号。

你可以对照几个问题来排查：

执行计划里有没有DEPENDENT SUBQUERY或UNCACHEABLE SUBQUERY？
外层表的预估行数有多大？如果外层要扫一百万行，而每条子查询都依赖外层当前行，那就是典型的“循环内查询”问题。
内层表是否走上了索引？如果走了全表扫描，并且这个全表扫描被嵌套在循环里，问题会非常严重。
有没有出现DERIVED和MATERIALIZED？物化结果大概有多大？是否能被索引利用？

如果以上排查下来，没有发现明显问题，那就根本不需要改写。我见过太多人单纯因为团队规范“禁止子查询”而去重写SQL，结果改写后的执行计划反而多了很多额外的排序和临时表。方案要服务于执行计划，而不是服务于感觉。

4.2 按执行计划形态决定改写策略

根据执行计划的不同，我会选择不同的改写方向，避免一刀切。

如果执行计划中确实存在相关子查询逐行执行的信号，而且外层基数太大，那么优先考虑把它改写成JOIN。比如原始写法是：

sql复制SELECT c.*
FROM customers c
WHERE (
    SELECT COUNT(*)
    FROM orders o
    WHERE o.customer_id = c.id
      AND o.status = 1
) > 5;

这是一个标量子查询，用于找出有效订单数量大于5的用户。由于内层查询依赖外层c.id，在8.0中也会采用逐行探测的方式，只是可以利用orders.customer_id索引。若外层20万行，每行都要扫描相关订单并统计数量，查询可能依然要花费数秒。这种场景可以改写为：

sql复制SELECT c.*
FROM customers c
JOIN (
    SELECT o.customer_id
    FROM orders o
    WHERE o.status = 1
    GROUP BY o.customer_id
    HAVING COUNT(*) > 5
) t ON t.customer_id = c.id;

改写后，内层先分组统计出一个较小的结果集，再与用户表连接，避免了外层20万次的相关查询。但注意，如果分组前的orders表极大，且status筛选后数据量依然庞大，这个派生表的物化过程又会成为新的瓶颈。所以改写方案依然需要以具体执行计划为准。

4.3 派生表拆临时表的具体操作

很多慢查询的根源是FROM子句派生表太大，物化后既无索引，又与外表做全表连接。遇到这类SQL，比较成熟的补救做法是“手动物化”——把派生的结果先写入一张临时表，再在临时表上建立索引，最后参与JOIN。

以订单报表为例。原本的SQL可能是：

sql复制SELECT c.name, t.total_amount
FROM customers c
JOIN (
    SELECT customer_id, SUM(amount) AS total_amount
    FROM orders
    WHERE order_time BETWEEN '2024-01-01' AND '2024-01-31'
    GROUP BY customer_id
) t ON t.customer_id = c.id
WHERE c.region = '华东';

如果这个派生表数据量有几十万行，再和几百万的customers表做JOIN，执行计划中很可能出现临时表全表扫描。我的处理方式是手动拆解：

sql复制CREATE TEMPORARY TABLE tmp_order_stat (
    customer_id INT PRIMARY KEY,
    total_amount DECIMAL(10,2),
    KEY idx_total (total_amount)
) ENGINE=InnoDB;

INSERT INTO tmp_order_stat (customer_id, total_amount)
SELECT customer_id, SUM(amount)
FROM orders
WHERE order_time BETWEEN '2024-01-01' AND '2024-01-31'
GROUP BY customer_id;

SELECT c.name, t.total_amount
FROM customers c
JOIN tmp_order_stat t ON t.customer_id = c.id
WHERE c.region = '华东';

这样做的核心价值在于：临时表的主键可以支撑JOIN过程中的快速查找，减少了数据重复物化和无法利用索引的问题。手动拆解会牺牲一些SQL的简洁性，但在数据量巨大且频繁执行的场景下，这种可控性往往比一条大SQL更值得。

4.4 用窗口函数取代部分相关子查询

MySQL 8.0引入了窗口函数，这给了我们另一种替代子查询的思路。比如我们需要找出每个用户最近的一笔有效订单，很多老一代开发会写相关子查询：

sql复制SELECT o.*
FROM orders o
WHERE o.order_time = (
    SELECT MAX(o2.order_time)
    FROM orders o2
    WHERE o2.customer_id = o.customer_id
      AND o2.status = 1
);

这条SQL在数据量稍大时通常表现很差，因为每一行都要执行一次子查询来找到用户的最大订单时间。更稳妥的做法是用窗口函数：

sql复制WITH ranked_orders AS (
    SELECT o.*,
           ROW_NUMBER() OVER (
               PARTITION BY customer_id
               ORDER BY order_time DESC
           ) AS rn
    FROM orders o
    WHERE o.status = 1
)
SELECT *
FROM ranked_orders
WHERE rn = 1;

窗口函数会在一次扫描中完成分组排序，避免了逐行相关查询。对于订单量千万级的表，这种写法的执行效率通常比老式相关子查询高出很多倍。但这个方案也有代价：如果order_time列上没有索引，窗口函数的排序依然可能很大；同时，该查询会先对全表做窗口排序，若每个用户的订单极多，内存排序压力就会上升。实际使用前仍然建议用EXPLAIN ANALYZE看一遍。

4.5 改写后的验收清单

我在团队里要求所有SQL改写必须经过一轮测试验收，不能只看“比原来快”就草率上线。维护一份简单的检查清单很有必要：

改写前后的数据集结果是否完全一致？可以通过EXCEPT或手工抽样核对。
新执行计划中是否还出现DEPENDENT SUBQUERY、UNCACHEABLE SUBQUERY、磁盘临时表等高危信号？
JOIN后的行数是否会因为一对多关系而膨胀？有没有用DISTINCT或聚合消除重复？
NOT IN改写后是否把NULL的处理逻辑考虑清楚？
真实数据量下执行时间是否在预期范围内？随机抽样一段业务高峰时段，观察是否有波动。

这套清单用下来，基本能避免“把子查询改成JOIN后又引入新故障”的低级问题。

5. 什么时候子查询反而是更优解

5.1 半连接语义本身就无法被普通JOIN干净替代

我一直强调一个观点：很多情况下，子查询不仅不该被禁用，反而比手写JOIN更优雅也更高效。原因在于SQL语义天然包含了“存在性判断”，也就是半连接。

比如这个语义：“找出所有下过有效订单的用户”。如果写成JOIN，同一用户可能拥有多张有效订单，最终用户行会被复制多份，必须加DISTINCT去重。去重的过程往往伴随着排序或临时表。而使用IN或EXISTS表达这个逻辑是最自然的，优化器执行时也是半连接语义，天然不会产生重复结果。

在实际线上压力测试中，我遇到过不只一次这样的对比：一条EXISTS子查询的执行计划是Nested loop semi join，耗时稳定在几百毫秒；而人工改成的JOIN + DISTINCT，因为引入了额外的排序操作，耗时反而翻了一倍。可见，优化器的优化器比人脑的记忆更可靠，我们不该用十年前的老眼光去限制新版本的SQL能力。

5.2 优化器版本不同，结论可能完全反转

如果在MySQL面试中被问到“为什么不用子查询”，我的回答思路已经和几年前完全不同了。我会先反问面试官：你用的是哪个版本？如果是MySQL 5.5，那这个结论没问题；如果是5.7或8.0，那问题就变成了“为什么现代版本的子查询已经很强了，还有人在禁用”。

MySQL 5.6引入了半连接优化，5.7增加了派生表合并，8.0进一步增强了子查询相关的转换和谓词下推能力。到今天，你写下的绝大多数IN、EXISTS子查询，优化器都已经具备把它们转成semijoin或antijoin的能力。子查询本身并不是一个性能瓶颈，真正容易被淘汰的是老旧的MySQL版本和不合理的索引设计。

我曾经做过一次印象很深的验证。某个旧系统里有一条经典的IN子查询慢SQL，当时的DBA给出的方案是改写为JOIN，并加了DISTINCT。后来业务迁移到MySQL 8.0，我顺手拿出来重新测试，发现原始子查询在8.0上的执行时间不比JOIN改写差，某些条件下甚至更快。这说明很多“优化”其实是在弥补旧版本优化器的缺陷，而不是在优化SQL逻辑本身。

5.3 不要因为祖训放弃可读性更好的SQL

代码的可读性和可维护性也是工程成本的一部分。子查询在很多时候比多层JOIN更容易理解。

举个常见的例子：查询“来自最近有退款记录订单的用户”。用子查询写：

sql复制SELECT *
FROM users
WHERE id IN (
    SELECT DISTINCT user_id
    FROM orders
    WHERE refund_flag = 1
      AND refund_time >= '2024-06-01'
);

这段SQL的逻辑非常直观，一个新接手的人一眼就能看出，子查询先提取出退款用户集合，再过滤用户表。如果强行改写成JOIN，代码会变成：

sql复制SELECT DISTINCT u.*
FROM users u
JOIN orders o ON o.user_id = u.id
WHERE o.refund_flag = 1
  AND o.refund_time >= '2024-06-01';

两段代码的业务含义相同，但第一段的结构更清晰地表达了“基于集合过滤用户”的意图。第二段则需要你意识到用户表可能因为一对多关系而出现重复，必须额外记住加DISTINCT。在维护复杂的BI报表或者数据服务时，这种认知负担积累下来是非常可怕的。

5.4 什么情况下我会手动干预子查询

说了这么多，并不是让所有人都无脑拥抱子查询。我在生产环境中依然会考虑手动改写，但这些干预都有明确的前提：

第一，执行计划出现确实无法通过添加索引或更新统计信息来改善的高危相关子查询。比如外层表超大，内层查询必须逐行计算且无法转半连接。这种情况下无论版本多新，都值得改写。

第二，派生表聚合成大结果集后无法利用索引。即使8.0版本，遇到不能合并的派生表且数据量庞大时，物化成本依旧可能拖垮整个查询。此时手动拆临时表、在临时表上建索引，效果通常比一条SQL硬扛要好。

第三，业务对延迟极其敏感，即使当前查询能在一秒内跑完，但这个查询会被高频调用，任何多余的循环或物化都会对数据库CPU造成压力。这时可以在不损失可读性的前提下，把子查询改成更直接的表达式或拆分为多步。

所以，与其说“MySQL不使用子查询的原因”，不如说“不懂执行计划的人不应该乱用子查询”。工具本身没有善恶，关键在于使用它的人是否理解背后的执行模型。我在评审SQL和培训团队时，不会一票否决子查询，而是要求每个写SQL的人都能主动跑一遍EXPLAIN，并且能在十秒内说出当前执行计划里有没有半连接、有没有物化、有没有相关子查询。做到这一点之后，你会发现子查询和JOIN的争论会自然消失——SQL世界里只有“适合当前数据和版本的写法”，没有永远正确的祖训。