嵌套子查询执行顺序是由内向外逐层求值，最内层SELECT先执行，结果逐层传递给外层；子查询必须先完成计算，外层才能依赖其结果进行过滤或投影，这是SQL语义强制要求，而非优化器可选行为。
嵌套子查询不是按代码书写顺序从外往里执行，而是由内向外逐层求值——最内层的 SELECT 先跑，结果传给上一层，以此类推。
子查询一定先于外层查询执行
数据库无法跳过依赖直接执行外层逻辑。比如 SELECT name FROM employees WHERE salary > (SELECT AVG(salary) FROM salaries)，AVG(salary) 不算出来，> 就没法比较。这不是优化器“选择”，而是语义强制要求。
- 即使子查询出现在
SELECT列表里（如标量子查询），也必须先完成计算才能填充结果列 - 若子查询返回多行而上下文只接受单值（例如用在
=左侧），会直接报错Subquery returns more than 1 row -
ORDER BY在子查询中被忽略（除非配合LIMIT做 Top-N 优化），因为子查询结果只是中间值，不对外暴露顺序
多层嵌套时执行路径是“深度优先”
像 SELECT * FROM t1 WHERE id IN (SELECT id FROM t2 WHERE x = (SELECT MAX(y) FROM t3)) 这种三层结构，实际执行流是：MAX(y) → t2 筛选 → t1 关联。每一层都等下一层返回确定结果后才继续。
- 不会出现“先扫描
t1再回头等子查询”的情况；主表扫描通常发生在最外层FROM阶段，但过滤条件中的子查询一定提前求值 - 如果某层子查询结果为空（如
IN (empty)），整条IN条件判定为FALSE，外层对应行被过滤掉 - 注意 NULL 处理：
NULL IN (subquery)结果是UNKNOWN，在WHERE中等效于FALSE，该行同样被排除
优化器可能重写，但语义执行顺序不变
你看到的执行计划里，子查询可能被转成 JOIN、物化为临时表，甚至被下推到索引扫描中——但这些只是实现手段。只要 SQL 语义没变，用户可感知的行为就仍是“先得子查询结果，再算外层”。
- 用
EXPLAIN查看时，子查询常显示为select_type=SUBQUERY或DERIVED，对应不同嵌套位置和优化策略 - 加
/*+ MATERIALIZE */提示可强制物化子查询结果，避免重复执行，但这不改变“它必须先跑完”这一事实 - 千万别靠空格或换行控制执行顺序——
SELECT/*+ LEADING(t1) */ ...这类 hint 只影响连接驱动顺序，对纯子查询的求值时机无效
真正容易被忽略的是子查询的“不可见副作用”：它不参与外层的 GROUP BY 分组、不受外层 LIMIT 限制、也不能引用外层的非相关列（除非显式关联）。这些边界决定了它必须是一个独立、先行完成的计算单元。
