SQL查询引擎执行原理_嵌套子查询的解析机制-SQL-PHP中文网

无关子查询执行一次，相关子查询可能每行外层数据都执行一遍；判断依据是子查询是否依赖外层字段，explain中select_type为dependent subquery即为相关。

sql查询引擎执行原理_嵌套子查询的解析机制

子查询到底执行几次？先看它是相关还是无关

无关子查询只执行一次，相关子查询可能每行外层数据都执行一遍——这是性能分水岭。比如 SELECT * FROM Product WHERE approvalStatus = (SELECT pk FROM ArticleApprovalStatus WHERE code = 'approved')，括号里不依赖外层字段，属于无关子查询，查一次就够了；但换成 SELECT * FROM Product p WHERE EXISTS (SELECT 1 FROM Order o WHERE o.productId = p.pk)，o.productId = p.pk 中的 p.pk 来自外层，就变成相关子查询，MySQL 可能为每一行 Product 都跑一遍内层查询。

判断方法：把子查询单独复制出来执行，能跑通就是无关；报错（比如提示列不存在）大概率是相关
EXPLAIN 看 select_type 字段：SUBQUERY 通常无关，DEPENDENT SUBQUERY 就是相关
相关子查询在百万级表上极易拖垮响应，别盲目套用“逻辑清晰”的写法

IN 和 EXISTS 谁更快？取决于子查询结果大小和索引

IN 和 EXISTS 表面功能相似，底层策略完全不同：IN 常触发物化（Materialization），把子查询结果建临时表再做哈希查找；EXISTS 更倾向走半连接（semi-join）或反向索引查找。但实际谁快，得看数据分布。

子查询结果小（IN 物化后 lookup 很快，可接受
子查询结果大（>1000 行）或无索引：EXISTS 更稳，避免建大临时表；但若外层表没索引匹配字段，也会退化成嵌套循环
特别注意：NOT IN 遇到 NULL 会整个返回空集，而 NOT EXISTS 不受 NULL 影响——这是语义坑，不是性能坑

MySQL 怎么“物化”子查询？临时表不是白建的

MySQL 没有独立“物化引擎”，但优化器会在判定子查询不可合并（non-mergeable）时，主动把它执行一遍，结果存进内存或磁盘临时表，再让外层查询去查这张表。这个过程叫 Materialization，它省了重复计算，但代价是建表 + 查表两步开销。

触发条件常见于：IN 后跟聚合子查询（如 SELECT id FROM t1 WHERE x IN (SELECT MAX(y) FROM t2 GROUP BY z)），或子查询含 GROUP BY/DISTINCT
临时表默认用 MEMORY 引擎，但超出 tmp_table_size 会自动转成 MyISAM 或 InnoDB 磁盘表，I/O 成倍增加
用 EXPLAIN FORMAT=JSON 查看 materialized_from_subquery 字段，能确认是否走了物化路径

SQLite 的“拍扁”和 MySQL 的“合并”不是一回事

SQLite 的 Subquery Flattening 是激进优化：直接把子查询逻辑下推进外层 WHERE，删掉嵌套结构，变成单层扫描。比如 SELECT a FROM (SELECT x+y AS a FROM t1 WHERE z5 会被拍成 SELECT x+y AS a FROM t1 WHERE z5。MySQL 也支持类似优化（称为 subquery merging），但更保守，只对简单无关子查询生效，且要求子查询不含聚合、窗口函数、LIMIT 等限制项。