为什么SQL中的非相关子查询只执行一次_理解缓存机制与执行计划-SQL-PHP中文网

非相关子查询只执行一次，因其不依赖外层表列（如无t1.id等引用），优化器会物化结果复用；可通过单独执行子查询不报错、EXPLAIN FORMAT=TREE显示-> Materialize确认。

为什么sql中的非相关子查询只执行一次_理解缓存机制与执行计划

非相关子查询只执行一次，不是语法规定，而是优化器主动做的“省事”动作——它识别出子查询不依赖外层数据，就把它拎出来单独算一遍，结果存进内存常量槽或临时物化表，后续全复用。

核心就一条：子查询里有没有出现外层表的列名（比如 t1.id、orders.user_id）。

没有——就是非相关，例如 (SELECT MAX(price) FROM products)、(SELECT value FROM config WHERE key = 'timeout')
有——就是相关，例如 (SELECT COUNT(*) FROM logs WHERE user_id = users.id)，哪怕只多写了一个点号，也会触发逐行重算
验证方法：把子查询整段复制出来，单独 SELECT 一把，能跑通且不报“Unknown column”就是非相关

不能只看 select_type 是 SUBQUERY 还是 DEPENDENT SUBQUERY，得结合执行计划结构来确认实际行为。

MySQL 8.0+：用 EXPLAIN FORMAT=TREE，如果看到子查询被包在 -> Materialize 下，说明已被物化，只执行一次
PostgreSQL：用 EXPLAIN (ANALYZE, VERBOSE)，若子查询显示 SubPlan 且 actual time=0.001..0.002 rows=1，且 never executed 没出现，基本就是单次计算
注意陷阱：DEPENDENT SUBQUERY 未必真“每行都跑”——某些版本会做 semi-join 优化，但只要子查询里写了外层列，就不能默认它被优化掉了

非相关 ≠ 绝对安全。以下几种写法会让优化器放弃物化，或者让单次执行本身就很重。

子查询含 LIMIT 但没 ORDER BY：MySQL 可能拒绝物化，因为结果不稳定
子查询引用了函数如 NOW()、RAND() 或用户变量 @var：优化器认为结果不可缓存，每次都会重求值
子查询返回多行多列却用在标量上下文（如 WHERE x = (SELECT a,b FROM t)）：会报错，但某些旧版 MySQL 只取第一行，还可能漏掉优化路径
SQLite 旧版本（

物化是优化，JOIN 是重写逻辑——两者目标不同，不能简单互换。

非相关子查询本质是“查一个常量”，比如 WHERE status = (SELECT id FROM status_codes WHERE code = 'active')；改成 JOIN status_codes ON ... 强制关联，可能引入多余行或 NULL 匹配，语义已变
如果子查询带聚合（如 AVG(salary)），JOIN 后再 GROUP BY 容易放大中间结果集，尤其是外层表大、聚合字段无索引时
真正该优先 JOIN 的，是那些本就该“一对多展开”的场景，比如“查每个部门的平均薪资”，而不是“查所有人的薪资是否高于全局平均”

最容易被忽略的一点：非相关子查询的“只执行一次”，完全依赖优化器能否静态判定其独立性。任何对外部上下文的隐式依赖（比如 session 变量、临时表、函数副作用），都会让这个假设失效——这时候看执行计划比背概念管用得多。