在SQL性能调优中如何通过执行计划分析子查询的驱动顺序-SQL-PHP中文网

子查询是否为驱动表取决于其在执行计划中的select_type和id：DERIVED类型且id较大时为驱动表，DEPENDENT SUBQUERY类型则为被驱动表，逐行执行导致性能陷阱。

在sql性能调优中如何通过执行计划分析子查询的驱动顺序

怎么看子查询在执行计划里是驱动表还是被驱动表

子查询是否成为驱动表，取决于优化器是否把它物化（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%，也已是性能瓶颈核心