SQL子查询全面解析：分类、执行原理与性能优化实战

SQL子查询是很多人的分水岭。会用它的人，能把一个复杂的业务需求拆成几个简单的小问题，一层层拼出优雅的查询；不会用的人，遇到复杂过滤就只有join、join、再join，最后结果对不对自己都说不清。子查询最大的价值，是把"查询的中间结果"当成一个独立的逻辑单元来复用——你可以先问"哪些用户是重点用户"，再问"这些用户的订单情况如何"，每一步都清晰可见。这篇文章我打算把这东西彻底讲透：分类、写法、执行原理、性能优化、高频报错，一次过完。适用于已经能写基础增删改查、但想突破复杂查询瓶颈的人，也适合那些被"子查询和join该选谁"困扰了很久的同学。

1. 子查询的三个分类维度：先搞清楚你在写哪一种

很多人看子查询的教程觉得乱，是因为教程一上来就堆十几个例子，却没告诉你子查询其实有三个完全独立的分类维度。这三个维度叠在一起，才组成了你看到的"某某子查询"。

1.1 按返回结果形状分类

这是最基础、也最好理解的分类。子查询本质上也是一条SELECT语句，既然是查询，它就有返回结果，而结果可以被分成四种形状：

标量子查询：返回一行一列，只有一个值。它在任何能写表达式的地方都能用，比如SELECT后面、WHERE后面。最典型的例子：

SELECT id, name, (SELECT MAX(total_amount) FROM orders) AS max_order_amount FROM users;

注意，如果标量子查询返回了多行，MySQL会直接报错：Subquery returns more than 1 row。所以写标量子查询时，要么用聚合函数把它压成一行，要么在子查询里加LIMIT 1。

行子查询：返回一行多列，通常配合括号展开的行构造器使用。比如我要找"每个订单里金额最高的那一行"，可以这样表达：

SELECT * FROM orders WHERE (user_id, total_amount) = (SELECT user_id, MAX(total_amount) FROM orders WHERE status = 'paid');

这里的(user_id, total_amount)是一个行构造器，子查询返回一行（某用户的最大支付金额），两者逐列比较。行子查询在日常业务里用得不算多，但一旦用到，能省掉你用两条查询拼接数据的麻烦。

列子查询：返回一列多行，典型搭配是IN。它是最常见的子查询形态之一：

SELECT id, name FROM users WHERE id IN (SELECT user_id FROM orders WHERE total_amount > 1000);

表子查询：返回多行多列，像一张临时表。它通常出现在FROM子句后面，也叫派生表。派生表必须要有一个别名，否则MySQL直接报错。这是一个新手极高频错误：

SELECT u.id, t.total_spend FROM users u JOIN ( SELECT user_id, SUM(total_amount) AS total_spend FROM orders WHERE created_at >= '2024-01-01' GROUP BY user_id ) t ON u.id = t.user_id;

这四种形状，从"一个值"到"一张表"，能力是逐渐增强的。你在写子查询之前，先问自己：我需要的中间结果到底是值、是一行、是一列、还是一张完整的表？答案清楚了，写法自然就有了。

1.2 按与外部查询的关联方式分类

非关联子查询：子查询可以独立运行，不依赖外层查询的任何字段。上面举的例子全都是非关联的。优化器处理这种子查询时很舒服，因为它可以先执行子查询，拿到完整结果，再继续处理外层，甚至可以把这个结果缓存下来重复使用。

关联子查询：子查询里出现了外层查询的列。比如：

SELECT u.id, u.name, (SELECT COUNT(*) FROM orders o WHERE o.user_id = u.id) AS order_count FROM users u;

内层子查询里的o.user_id = u.id用到了外层的u.id，这个子查询没法独立运行——它依赖外层正在处理的那一行是谁。理解这个概念很重要，因为它的执行逻辑和性能特性和非关联子查询完全不同，后面第三章我会专门拆解。

1.3 按出现位置分类

同一个子查询，可以出现在SQL语句的不同位置，学起来最乱的就是这里。我用一个表格把它们归置清楚：

把这三个维度合在一起看，你就明白了：WHERE id IN (SELECT ...)是"非关联的列子查询"，SELECT (SELECT ... FROM orders WHERE o.user_id = u.id)是"关联的标量子查询"，FROM (SELECT ...) t是"非关联的表子查询"。以后看到任何一段子查询代码，你能在脑子里自动把它的分类标出来，这就比死记硬背语法高一个段位了。

2. 六大应用场景的写法与索引视角

2.1 WHERE后面用子查询做筛选

这是出现频率最高的场景。它的本质是：外层表的一行数据，要跟一个动态的集合做匹配。最常见的搭配有IN、EXISTS、以及直接跟比较运算符。

-- 查所有下过单的用户 SELECT id, name FROM users WHERE id IN (SELECT user_id FROM orders); -- 查2024年消费超过2000的用户 SELECT id, name FROM users u WHERE EXISTS ( SELECT 1 FROM orders o WHERE o.user_id = u.id AND o.total_amount > 2000 );

关于IN和EXISTS怎么选，我后面专门用一章展开讲。这里只提醒一点：WHERE子查询的过滤效果，最终要看索引能不能被用上。WHERE id IN (SELECT user_id FROM orders)这种写法，如果orders.user_id没有索引，内层查询必然做全表扫描；如果外层表的数据量也很大，整体性能会非常难看。在写任何WHERE子查询之前，先想清楚内层结果集有多大，外层表有多大，以及两边的关联字段上有没有索引。

2.2 FROM后面用派生表做中间集合

派生表的核心应用场景是"先聚合、再关联"。不要在JOIN里面直接对明细表做聚合，那几乎一定会引入笛卡尔积或重复数据。正确思路是把聚合结果先做成一张小表，再和主表关联：

SELECT u.id, u.name, m.total_spend FROM users u JOIN ( SELECT user_id, SUM(total_amount) AS total_spend FROM orders WHERE status = 'paid' GROUP BY user_id ) m ON u.id = m.user_id WHERE m.total_spend > 5000;

这里的关键在于：MySQL会把派生表先执行、物化为一张临时表，然后外层再做JOIN。如果派生表只需要几十行、几百行，执行速度会非常快；如果派生表本身就要扫几百万行，那无论外层怎么优化都救不回来。所以性能瓶颈往往在派生表内部，而不是在外层的JOIN上。

另外，派生表的别名不是可选项，是强制项。你没写别名的时候，MySQL会报Every derived table must have its own alias，这个错误几乎每个人都会遇到一次。

2.3 SELECT后面用标量子查询做动态计算列

有时候你想在结果集里带出"关联数据的一个值"，不想为此再写一个JOIN，就可以用标量子查询。比如每个用户的最近一次下单时间：

SELECT u.id, u.name, (SELECT MAX(created_at) FROM orders o WHERE o.user_id = u.id) AS last_order_time FROM users u;

这个写法在数据量小的时候很爽，但注意它的执行逻辑：外层表每返回一行，内层子查询就要执行一次。users表有10万行，这个标量子查询就被执行10万次。如果内层子查询能命中索引，10万次短查询还扛得住；一旦没索引，就是10万次全表扫描，线上接口不慢才怪。

一个常用优化思路是改用LEFT JOIN加分组：

SELECT u.id, u.name, MAX(o.created_at) AS last_order_time FROM users u LEFT JOIN orders o ON u.id = o.user_id GROUP BY u.id, u.name;

当然这也要注意GROUP BY的字段要完整，否则结果集语义会出问题。SELECT后面的标量子查询，适合"外层结果集本来就很小、且内层索引稳定命中"的场景；一旦两张表都是大表，优先考虑JOIN聚合。

2.4 HAVING里用子查询做组级过滤

HAVING里面也可以用子查询，但很多人不知道。它的语义是：先GROUP BY分组，再用子查询结果对组进行过滤。比如我只想看"订单数超过全站平均订单数"的月份：

SELECT DATE_FORMAT(created_at, '%Y-%m') AS month, COUNT(*) AS order_cnt FROM orders GROUP BY DATE_FORMAT(created_at, '%Y-%m') HAVING order_cnt > ( SELECT COUNT(*) FROM orders );

这个例子可能不太严谨，但表达的意思是清楚的：HAVING子句后的子查询，是对整个分组结果做比较。需要留意的是，HAVING子查询的执行时机是在分组之后，所以子查询里的数据范围要仔细想清楚，是要全表平均值，还是要外部分组的平均值，这两种语义完全不同。

2.5 JOIN ON里用子查询做匹配条件

JOIN的ON条件里放子查询，本质上是把一个过滤结果集作为关联对象。它和FROM派生表有点像，但位置不同：FROM派生表是"先建好一张表，再JOIN"，ON子查询是"在关联的同时做条件过滤"。

SELECT o.id, o.total_amount FROM orders o JOIN ( SELECT user_id, MAX(created_at) AS latest_time FROM orders WHERE status = 'paid' GROUP BY user_id ) latest ON o.user_id = latest.user_id AND o.created_at = latest.latest_time;

这个例子是找每个用户最近一笔支付订单。这里的派生表先算好了"每个用户最近支付时间"，然后外层订单表和它按用户+时间双条件匹配。如果不这么做，很自然地就会写出三层嵌套的相关子查询，性能要差很多。

2.6 UPDATE/DELETE里用子查询做批量条件

子查询不是SELECT的专利，UPDATE和DELETE的条件里也能用。比如把"从未下单用户"标记为停用：

UPDATE users SET status = 'disabled' WHERE id NOT IN ( SELECT user_id FROM orders );

但这里有一个MySQL特有的坑：如果你尝试在同一条UPDATE/DELETE语句里，直接对orders表做查询，然后再更新orders表，比如：

DELETE FROM orders WHERE id IN ( SELECT id FROM orders WHERE total_amount < 0 );

MySQL会直接报错：You can't specify target table 'orders' for update in FROM clause。原因是MySQL不允许从目标表读取数据的同时修改它。解决办法很简单，包一层派生表：

DELETE FROM orders WHERE id IN ( SELECT id FROM ( SELECT id FROM orders WHERE total_amount < 0 ) t );

这个"套娃"技巧很实用，很多从旧项目里接手MySQL的人第一次见到这个报错都会有点懵。

3. 相关子查询的执行语义：为什么它可能慢

3.1 逐行执行的底层逻辑

要理解相关子查询为什么慢，必须理解它的执行模式。对于一个非关联子查询，MySQL的执行顺序大致是：先执行子查询，把结果记在临时结果里，再去执行外层查询。就像你进便利店买东西，先查好所有商品价格，再决定买什么。

但关联子查询不一样。它没法独立执行，因为内层查询依赖外层当前行的值。它的执行方式更像嵌套循环：

SELECT u.id, u.name, (SELECT COUNT(*) FROM orders o WHERE o.user_id = u.id) AS cnt FROM users u;

实际执行时，相当于伪代码这样跑：

对于 users 表中的每一行 u： 执行 SELECT COUNT(*) FROM orders o WHERE o.user_id = u.id 把结果放到结果集的 cnt 列

也就是说，外层表有多少行，内层查询就被触发多少次。如果users表有5万行，内层子查询就被执行5万次。每次都代表一次独立的查询调度、一次索引查找或扫描。这和JOIN的批量执行模式有本质差异。

这也是为什么很多新手写出来的"看起来很聪明"的子查询，在百万级数据上跑得比蜗牛还慢。子查询本身没有错，但你要清楚地知道自己在用什么执行模型。

3.2 EXPLAIN输出里的三种执行策略

通过EXPLAIN查看执行计划，是定位子查询性能问题的第一步。不同形态的子查询，在EXPLAIN里会呈现不同的关键字：

传统EXPLAIN输出里面，你看到一个DEPENDENT SUBQUERY，就要警惕了，这个字段本身就说明SQL在走"逐行执行"的模型。它不是说一定会很慢，而是提醒你：这个查询的性能取决于外层表行数乘以内层查询单次开销。

MySQL 8.0里可以直接用EXPLAIN FORMAT=TREE，看树形结构更直观。执行计划里如果出现Materialize、Initialize这样的节点，说明优化器把子查询结果物化成了一张内部临时表，这通常不算坏事，因为它把"逐行执行"变成了"先算一次，再匹配"。

3.3 相关子查询的提速手段

让相关子查询变快，核心思路只有一个：压缩内层查询单次开销。具体有三种手段。

第一，给关联字段加索引。相关子查询本质上是反复执行内层查询，内层查询如果能命中索引，单次开销就从全表扫描变成一次索引查找。上面那个例子，如果orders(user_id)没有索引，那每次执行都是全表扫描，几十万行表你扫几万次，整个查询一小时都跑不完；加上索引后，单次查询可能是0.1毫秒量级，整体立刻可用。

第二，尽量让外层表变小。WHERE条件提前过滤掉不必要的外层行，相关子查询的执行次数就直接减少。比如加一个u.status = 'active'条件，外层只剩活跃用户，执行次数降一个数量级，效果立竿见影。

第三，把重复计算提到查询外面。有些所谓"相关子查询"其实可以改写成非关联的。比如统计每个用户订单数，本质上一句GROUP BY就能算出来，没必要把聚合函数放进相关子查询里：

-- 相关子查询写法 SELECT u.id, (SELECT COUNT(*) FROM orders o WHERE o.user_id = u.id) AS cnt FROM users u; -- 更高效的思路：先聚合再关联 SELECT u.id, COALESCE(t.cnt, 0) AS cnt FROM users u LEFT JOIN ( SELECT user_id, COUNT(*) AS cnt FROM orders GROUP BY user_id ) t ON u.id = t.user_id;

两者语义在某些场景下略有差别（比如0和NULL），但性能往往差一个数量级。先聚合再关联，聚合结果集只有用户数那么多个组，跟全表行数差太远了。

4. IN、EXISTS、JOIN的三选一：找到性能和语义的平衡点

4.1 语义差异：去重、NULL与三值逻辑

很多人纠结IN和EXISTS到底谁快，其实在小数据量上两者几乎没有区别，真正要紧的是语义差异。

IN子查询意味着"外层的某个值，是否存在于子查询返回的集合里"。这个集合的去重和NULL问题由SQL自己处理。先说去重，IN的语义天然是"存在即匹配"，子查询返回重复值不会导致外层行重复，所以不用手动DISTINCT。而JOIN没有这个语义，如果关联上的数据在右表有多条，外层行就会被重复展开，造成结果集行数暴增。这是IN改写为JOIN时最容易踩的坑——结果对不上，多了一堆重复数据。

再说NULL。这里必须引入SQL的三值逻辑：SQL里的比较结果不只是TRUE和FALSE，还有第三个值UNKNOWN。任何和NULL做比较的表达式，结果都是UNKNOWN。UNKNOWN在WHERE里不满足过滤条件，所以行会被淘汰。

IN实际上是多个等值比较的OR拼接：

WHERE id IN (1, 2, NULL) -- 等价于 WHERE (id = 1) OR (id = 2) OR (id = NULL)

第3个比较id = NULL的结果永远是UNKNOWN，但它不影响整个OR表达式的真假，因为前两个可能已经为TRUE了。

NOT IN就危险了，它是整个表达式的取反：

WHERE id NOT IN (1, 2, NULL) -- 等价于 WHERE NOT ((id = 1) OR (id = 2) OR (id = NULL))

问题在于，只要子查询结果集里出现一个NULL，id = NULL就是UNKNOWN，整个OR表达式里只要有一个UNKNOWN，无论其它项是TRUE还是FALSE，整个表达式都可能是UNKNOWN或TRUE，反正永远不会变成FALSE，导致整个查询一行都不返回。

用一句话总结：只要NOT IN的子查询结果里可能包含NULL，就别写NOT IN。要么在建表时给关联字段加NOT NULL约束，要么在子查询里提前过滤掉NULL：

SELECT id, name FROM users WHERE id NOT IN ( SELECT user_id FROM orders WHERE user_id IS NOT NULL );

更稳妥的替代方案，是用NOT EXISTS，它处理NULL的方式完全不同，后面会讲。

4.2 半连接优化与NOT IN的经典陷阱

MySQL 5.6之后引入了半连接优化，优化器会把符合条件的IN子查询自动改写为半连接执行，逻辑上有点像JOIN但只返回左表匹配的行，且不产生重复。这也是为什么现在的MySQL里，很多IN子查询并不慢。但半连接优化是有条件的，常见不能改写的情况就包括：子查询里带LIMIT、带聚合函数、带GROUP BY、带用户变量等。

NOT IN的NULL陷阱我已经说过了，我还要补充一个实际场景的排查过程。有一次我们在某个报表模块看到一条查询：

SELECT COUNT(*) FROM users WHERE id NOT IN ( SELECT user_id FROM orders WHERE created_at >= '2024-01-01' );

结果永远是0，业务上完全说不通。排查链路是这样的：

第一步，确认orders.user_id字段的默认值。一查表结构，果然user_id允许NULL，并且历史脏数据里确实有大量NULL值。第二步，手工执行SELECT DISTINCT user_id FROM orders WHERE created_at >= '2024-01-01'，结果集合里带NULL。第三步，用NOT EXISTS改写。第四步，结果集立刻从0变成上万。

这就是NULL陷阱最经典的呈现方式：查询不报错，语义上就是错的，而且你如果不知道三值逻辑，根本猜不到问题出在哪。所以我把这条规律当铁律记着：所有NOT IN子查询，默认都要假设子查询结果里可能出现NULL，然后强制过滤或用NOT EXISTS改写。

4.3 不同场景下的改写建议

我按自己的经验，给出一套实用的选择标准：

这里有个常见误区：认为EXISTS一定比IN快。实际上MySQL优化器已经做了不少半连接改写，在很多场景下IN和EXISTS最终执行计划是一样的。真正决定性能的，是两边的数据量、关联字段索引覆盖情况，以及子查询内部是否被优化器拦截。

NOT EXISTS和NOT IN也有一个容易踩的坑：NOT EXISTS关联子查询的关联条件一旦写错，比如漏了o.user_id = u.id，那子查询就是独立查询，语义完全改变，结果也会错得离谱。所以改写NOT IN时一定要检查关联条件是否完整。

5. 实战排查：一条慢查询是如何被救活的

5.1 现场还原：慢在哪里

某个业务报表里有一条查询，每次跑都要20秒以上，日志里频繁刷出慢查询告警。简化后的语句大致是这样：

SELECT u.id, u.name, u.status, (SELECT COUNT(*) FROM orders o WHERE o.user_id = u.id AND o.created_at >= '2024-01-01') AS order_cnt FROM users u WHERE u.created_at >= '2023-01-01';

users表有约30万行，orders表有约800万行。乍一看，这是个典型的"SELECT后放相关标量子查询"的写法，外层经过时间过滤后大约还有15万行，意味着内层子查询要被触发15万次。orders表上user_id有索引，但created_at上没有索引，导致每次内层查询还要做一次时间范围过滤。

这不是某个特定环境的偶发问题，而是这类写法在数据量上来之后的必然结果。相关子查询的逐行执行模型，注定了它扛不住大的外层行数。

5.2 排查链路与定位手段

第一步，EXPLAIN看执行计划。输出里能看到关联子查询被标记为DEPENDENT SUBQUERY，这直接说明了执行模型是逐行执行的。同时还要看type列，如果出现了ALL，说明在走全表扫描，性能必然崩。

第二步，拆解单次内层查询的成本。手工执行：

SELECT COUNT(*) FROM orders o WHERE o.user_id = 12345 AND o.created_at >= '2024-01-01';

发现单次执行也要几十毫秒，因为created_at上没有索引，加时间条件后走的是user_id索引回表，再过滤日期。单次几十毫秒乘以15万次，就是几十分钟级别。这条查询跑了20秒，说明实际外层过滤比预想多，或者MySQL做了部分缓存，但方向已经很明确了。

第三步，查看整体数据分布。SELECT COUNT(*), COUNT(DISTINCT user_id) FROM orders，确认每个用户平均订单数，以及2024年有订单的用户占比，这能帮助判断改写方向。

5.3 修复方案与验证

方案一：给orders表加复合索引(user_id, created_at)。这一步能把单次内层查询从几十毫秒压到几毫秒，因为索引已经覆盖了关联字段和过滤字段，不需要回表。

ALTER TABLE orders ADD INDEX idx_user_created (user_id, created_at);

方案二：把相关子查询改写为"先聚合、再关联"的非关联查询：

SELECT u.id, u.name, u.status, COALESCE(t.order_cnt, 0) AS order_cnt FROM users u LEFT JOIN ( SELECT user_id, COUNT(*) AS order_cnt FROM orders WHERE created_at >= '2024-01-01' GROUP BY user_id ) t ON u.id = t.user_id WHERE u.created_at >= '2023-01-01';

改写后的执行模型完全变了：子查询只执行一次，先按用户分组统计，然后外层LEFT JOIN。关键点在于，每个用户只对应一行聚合结果，所以不会产生重复数据。加不加COALESCE取决于业务上是否区分"没有订单"和"订单数为0"。

两个方案都验证后，查询从20秒降到了0.3秒左右。而且LEFT JOIN改写之后，EXPLAIN里看不到DEPENDENT SUBQUERY了，出现的是DERIVED。这意味着主查询变成了"派生表+关联"的结构，MySQL可以用hash join或索引关联把数据批量处理，而不是逐行反复执行子查询。

这条排查给我的经验是：遇到慢查询，先看执行计划，确认执行模型，再改写法。很多时候不是你写的SQL"不对"，而是它触发了一个不适合当前数据量的执行模型。模型选对了，性能立刻就稳定了。

6. 子查询的边界限制与高频报错

6.1 语法层面的硬限制

MySQL对子查询有一些语法边界，如果你不知道这些边界，报错会来得莫名其妙，而且搜索引擎也不一定能直接搜到答案。

第一个硬限制是：From子句里的派生表不能直接引用外层查询的列。标准SQL里，FROM子句的子查询是在外层查询执行前物化的，它看不到外层表的字段。如果你试图在派生表里写WHERE o.user_id = u.id，MySQL会直接报错，提示找不到列。这个问题在MySQL 8.0里有了LATERAL关键字可以解决，见下一节。

第二个硬限制是：标量子查询只能返回一行一列。多行报错Subquery returns more than 1 row，多列报错Operand should contain 1 column(s)。这两个错几乎每个写子查询的人都会遇到。

第三个硬限制：在某些版本的MySQL里，IN子查询的ORDER BY和LIMIT不生效，或者结果不符合预期。MySQL 5.6之前，WHERE col IN (SELECT ... ORDER BY ... LIMIT ...)本身就不被优化器保证语义。如果你真想对子查询结果排序后取前几条，更稳妥的写法是把子查询放到FROM里做派生表再JOIN。

第四个硬限制：UPDATE/DELETE不能直接查询目标表，前面已经详细说过，要包一层派生表。

6.2 高频报错的成因与解决

我整理了一个高频报错清单，按出现频率排序，每个都是真实踩过的坑：

遇到报错，我的排查顺序是：先确认子查询的位置，再确认返回结果的形状，最后确认是不是引用了不该引用的外层字段。80%的子查询报错都可以靠这三步定位。

6.3 LATERAL派生表与MySQL 8.0的新选择

MySQL 8.0.14引入了LATERAL派生表，它解决了一个长期痛点：FROM子句里的派生表无法引用前面表的列。有了LATERAL，你可以在派生表里写关联子查询，让"每行用户都携带最近N条订单"这个需求变得非常优雅。

SELECT u.id, u.name, r.total_amount, r.created_at FROM users u JOIN LATERAL ( SELECT order_id, total_amount, created_at FROM orders o WHERE o.user_id = u.id ORDER BY created_at DESC LIMIT 3 ) r ON TRUE;

这个查询对每个用户，执行一次LATERAL派生表，取最近的三笔订单。注意几点：第一，LATERAL必须出现在子查询和FROM关键字之间；第二，子查询里可以引用前面已经出现的表（这里是u）；第三，外层用了JOIN LATERAL ... ON TRUE，实际上是交叉关联。

如果用传统写法，你会怎么实现"每个用户最近三笔订单"？先给订单按用户分组排序，再想办法取每组前三条。如果不用窗口函数，就得写一堆复杂的关联子查询，甚至用变量。LATERAL对这种"逐行关联聚合"的需求，是一个很自然的表达方式。当然，它的执行模型依然是逐行，所以性能上依然要关注内层索引，不要觉得用了LATERAL就万事大吉。

除了LATERAL，MySQL 8.0还改善了优化器的物化策略，很多子查询会被自动物化后走hash join，性能比以前稳定不少。但这也带来一个新问题：物化临时表要占内存和磁盘，超大子查询结果集会挤压buffer pool。遇到子查询返回几十万行结果的场景，还是要反过来想想，是不是在业务逻辑上就能先收敛数据量。

我现在的习惯是，写任何子查询之前先在草稿上画两笔数据量：外层大概多少行，子查询大概多少行，两边字段的索引是什么。数据量小的项目，怎么写都行；数据量上去了，一套固定的"先EXPLAIN、再确认执行模型、按需改写"的流程，远比我记一堆"IN快还是EXISTS快"的口诀可靠得多。子查询不是洪水猛兽，也不是银弹，它就是SQL世界里的普通工具，用对位置，它能让你的查询设计清晰一大截。