非相关子查询只执行一次，因为优化器能静态识别其不依赖外层表，从而提前物化结果；若含NOW()、RAND()、用户变量或隐式别名污染等，则会退化为重复执行。

先说一个关键发现：非相关子查询确实只需要执行一次，这不是什么玄学，而是数据库优化器的标准行为。核心机制在于，优化器通过静态分析就能识别出子查询与外层表没有依赖关系——既然没关系，那就提前算一次，把结果缓存起来，这就是所谓的物化（materialize）。

那么，怎么在真实的执行计划里验证这一点？答案就在你能拿到的那些工具里：

• MySQL 中看到 select_type: SUBQUERY（注意不是 DEPENDENT SUBQUERY）
• PostgreSQL 中看到 InitPlan 节点，且没有 Correlated Subquery 标记
• Oracle 中显示为 UNION ALL 或独立的 VIEW 步骤，而非嵌套循环

换句话说，只要子查询里没出现像 e.department_id、t1.id 这类指向外层表的列引用，优化器就会毫不犹豫地把它拎出来，单独算一次，然后大家共享结果。

哪些写法会让非相关子查询“假相关”？

表面看起来人畜无害、不引用外层，结果优化器却把它判为相关，导致重复执行——这是最隐蔽也最折磨人的性能陷阱。下面几种情况值得警惕：

• NOW()、RAND()、UUID() 等不确定性函数：优化器认为结果每次都可能不同，没法缓存，于是每行都重新算
• 子查询包含 LIMIT 但没有 ORDER BY：MySQL 可能直接拒绝物化，因为结果本身就不稳定
• 引用用户变量（比如 @counter := @counter + 1）：状态依赖导致无法复用
• 子查询中误写了外层别名却未实际使用（例如 SELECT * FROM employees e WHERE e.id IN (SELECT id FROM departments)，虽然 e.id 在子查询里没出现，但别名污染可能干扰解析）。这些细节，一不小心就踩坑。

标量子查询（SELECT 列里的子查询）真的一次性执行吗？

答案是：是的，但前提是它确实是标量且非相关——否则就会退化为逐行执行，性能灾难随之而来。

安全写法的典型代表：

• SELECT name, (SELECT COUNT(*) FROM departments) AS dept_count FROM employees ✅
• SELECT id, (SELECT MAX(updated_at) FROM config_log) AS last_sync FROM users ✅

危险写法则要特别留心：

• SELECT id, (SELECT COUNT(*) FROM orders WHERE user_id = users.id) ❌（这是相关子查询，users.id 是外层引用，每行都要重新算）
• SELECT id, (SELECT value FROM config WHERE key = 'timeout' AND updated_at > NOW() - INTERVAL 1 DAY) ❌（NOW() 导致每次重求值，哪怕子查询本身没问题）

物化结果太大反而拖慢？什么时候该换 JOIN？

非相关子查询只执行一次，并不意味着它永远快——物化成本本身可能成为新的瓶颈。比如，当子查询返回的是百万级行时（比如 SELECT * FROM huge_log_table WHERE status = 'error'），即使只跑一遍，构建临时表的内存或磁盘开销也足够卡死整个查询。

这时改写就需要权衡三点：

• 子查询是否真的需要全量结果？能不能先加 WHERE 把范围缩小？
• 主查询对子查询结果做的是 IN 还是 = 匹配？如果条件允许，可以转为 JOIN 并利用索引字段关联，往往更高效
• 聚合类子查询（如 A VG(salary)）通常不适合直接改写成 JOIN——JOIN 后再聚合容易把中间结果集放大，尤其在外层表很大的时候，得不偿失

最容易被忽视的一点是：物化是优化器的性能优化手段，而不是语义上的保证。一旦子查询中包含了不确定性因素或隐式依赖，所谓“只执行一次”就只是一种幻觉。在实际调优时，多留一个心眼，总没坏处。