子查询是否为驱动表取决于其在执行计划中的select_type和id：DERIVED类型且id较大时为驱动表，DEPENDENT SUBQUERY类型则为被驱动表，逐行执行导致性能陷阱。
怎么看子查询在执行计划里是驱动表还是被驱动表
子查询是否成为驱动表，取决于优化器是否把它物化（materialized）或展开（unnested）。如果子查询出现在 FROM 子句中（如派生表），它大概率会先执行并生成中间结果集，成为驱动表；如果出现在 WHERE 或 SELECT 中且未被展开（例如相关子查询），它通常作为被驱动表，对主表每行执行一次——这正是性能陷阱的高发区。
关键判断依据是执行计划中的 id 和 select_type 字段：
-
select_type = DEPENDENT SUBQUERY：说明该子查询依赖外部行，每次都要重算，是典型的被驱动行为 -
select_type = DERIVED：子查询被物化为临时表，独立执行一次，属于驱动表 -
id值比外层大：MySQL 中 id 越大越先执行，所以高 id 的子查询往往是驱动端
为什么相关子查询容易变成“N次循环”
相关子查询（correlated subquery）因引用了外层列，无法提前物化。优化器只能选择 Nested Loop 方式：对外表每一行，都执行一遍子查询。当外表返回 10 万行，子查询又没走索引，就等于执行了 10 万次全表扫描。
典型危险写法：
SELECT o.order_id FROM orders o WHERE o.customer_id IN ( SELECT c.customer_id FROM customers c WHERE c.status = 'active' );
即使 customers.status 有索引，IN 子查询仍可能被当作相关子查询处理（尤其 MySQL 5.7 及更早版本）。实际执行计划中会出现：
select_type = DEPENDENT SUBQUERY-
type = ALL（全表扫描） -
rows值反复出现，且与外表行数相乘后远超预期
如何强制子查询先执行（驱动优先）
不是所有子查询都能被优化器自动物化，尤其涉及聚合、LIMIT、GROUP BY 或非确定性函数时。这时需手动干预：
- 把子查询改写为
JOIN：将IN改成INNER JOIN，让优化器明确关联意图 - 用
WITH（CTE）显式声明物化：PostgreSQL / Oracle / SQL Server 2022+ / MySQL 8.0+ 都支持，但注意 MySQL 默认不物化 CTE，需加MATERIALIZED提示（/*+ MATERIALIZE */） - 在子查询外层套一层
FROM (SELECT ...) AS t：强制 MySQL 视其为DERIVED，触发物化（适用于 MySQL） - 避免在子查询中使用外层别名参与计算：比如
WHERE c.id = o.id * 2会阻止 unnest，换成等值条件更安全
执行计划里哪些信号说明子查询驱动失败
真正要警惕的不是“有没有子查询”，而是“有没有代价爆炸”。重点盯这几个字段组合：
-
select_type = DEPENDENT SUBQUERY+type = ALL+rows > 1000：基本可判定已陷入 N×M 循环 -
Extra列含Using temporary; Using filesort：说明子查询结果无法流式处理，被迫落盘，IO 成倍增加 - 同一子查询在不同
id层反复出现，且Starts（Oracle/SQL Server）或filtered（MySQL）值异常低：表明估算严重失准，驱动顺序被误判 - 子查询所在行的
Cost占总 Cost 超过 70%：即使它只占 SQL 文本 20%，也已是性能瓶颈核心
子查询驱动顺序不是靠猜，而是靠看 select_type 和 Starts/rows 的乘积。最容易被忽略的是：即使执行计划显示子查询“只执行一次”，只要它是 DEPENDENT 类型，就仍可能在运行时被重复调用——因为计划是预估的，而真实行为取决于数据分布和绑定变量值。
