EXPLAIN中识别子查询执行节点需看select_type列为SUBQUERY或DEPENDENT SUBQUERY，后者表示外层每行都触发一次执行；id大于1且table为<derivedN>或<subqueryN>说明物化，type为ALL/index、rows异常高、Extra含Using temporary/filesort则表明性能隐患。
EXPLAIN 输出里怎么看子查询执行节点
子查询在执行计划中不会单独标出“子查询”字样，而是以特定 select_type 值和嵌套结构体现。MySQL 的 EXPLAIN 结果中，关键识别点是：
-
select_type列为SUBQUERY（非相关子查询）或DEPENDENT SUBQUERY（相关子查询）——后者最危险，意味着外层每行都触发一次子查询执行 -
id列数值大于 1，且该id对应的行在table列显示为<derivedN>或<subqueryN>，说明它被物化为临时表或延迟求值 -
type列为ALL或index，且rows值异常高（比如几十万），说明子查询本身没走索引、在全表扫描 -
Extra列出现Using temporary或Using filesort，尤其在子查询对应id行上，代表内部排序/临时表开销大
相关子查询（DEPENDENT SUBQUERY）为什么特别慢
相关子查询不是一次性执行，而是随外层结果集逐行驱动，形成“N × M”级复杂度。比如外层查出 10 万用户，子查询每次都要重新扫描订单表找匹配记录，实际执行次数就是 10 万次。
- MySQL 5.7 及之前版本几乎无法将
DEPENDENT SUBQUERY重写为 JOIN，优化器基本放弃改写 - 即使子查询只返回 1 行，只要
select_type = DEPENDENT SUBQUERY，就已暴露性能隐患 - 常见写法如
WHERE price > (SELECT AVG(price) FROM products p2 WHERE p2.category = p1.category)就是典型相关子查询 - EXPLAIN 中若看到同一
table名反复出现在多个不同id行，且select_type交替为PRIMARY和DEPENDENT SUBQUERY，基本可判定存在嵌套循环放大
用 EXPLAIN ANALYZE 看真实耗时分布（PostgreSQL / MySQL 8.0+）
EXPLAIN 只给预估，EXPLAIN ANALYZE 才暴露子查询的真实瓶颈。它会显示每个节点的实际执行时间、循环次数和数据量。
- PostgreSQL 中重点关注
Actual Total Time和Actual Loops：如果某子查询节点Actual Loops是外层行数，且单次Actual Total Time虽小但乘积巨大，就是相关子查询证据 - MySQL 8.0+ 支持
EXPLAIN FORMAT=TREE，能直观看到子查询嵌套层级；配合EXPLAIN ANALYZE可见execution_time和loop_count - 注意：运行
EXPLAIN ANALYZE会真实执行 SQL，生产环境慎用；建议先用EXPLAIN定位可疑id，再对单条语句做分析 - 若子查询节点显示
Materialize（MySQL）或CTE Scan（PostgreSQL），说明优化器已尝试缓存结果，但若缓存后仍慢，大概率是物化过程本身开销大
别只盯子查询本身，看它和外层的连接方式
真正拖慢查询的，往往不是子查询逻辑多复杂，而是它和主查询之间缺乏高效关联路径。
- 检查子查询是否引用了外层字段（如
WHERE t1.id = t2.ref_id）——这是相关性的根源，也是改写为 JOIN 的突破口 - 确认外层表和子查询涉及的表是否有联合索引覆盖关联字段+过滤条件，例如子查询含
WHERE status='active' AND create_time > ?，则索引应为(status, create_time) - 如果子查询用了
GROUP BY或DISTINCT，但外层只用其中一列做等值判断，可考虑提前物化成派生表，避免重复聚合 - 某些场景下，把子查询提到
FROM子句作为派生表（SELECT * FROM main JOIN (SELECT ...) AS sub ON ...），比留在WHERE中更易触发哈希连接
子查询是否低效，不能只看语法像不像“子查询”，得看执行计划里它是不是被当作黑盒反复调用、有没有被物化、和外层有没有可利用的索引路径——这些细节藏在 select_type、id、Extra 和实际循环次数里，漏看任意一项都可能误判。
