SQL嵌套查询执行顺序自内向外，由逻辑依赖和执行模型决定：子查询必须先完成才能驱动外层操作；非相关子查询被物化一次，相关子查询每行触发一次；NOT IN遇NULL返回unknown致空结果，EXISTS则短路安全；标量子查询若无外层依赖可提前计算；实际路径以EXPLAIN为准。
SQL嵌套查询执行顺序确实是自内向外，但这个“自内向外”不是语法书写顺序的机械解读，而是由查询逻辑依赖和数据库执行模型共同决定的——子查询结果必须先就位，外层才能继续。
WHERE 中的子查询必须先执行完才能进入主表扫描
当 WHERE 条件里出现 (SELECT ...)，数据库不会边读主表边跑子查询。它必须先把子查询完整执行一遍，拿到确定的结果集（哪怕为空），再用这个结果去驱动后续过滤。
- 常见错误：
ERROR 1054 (42S22): Unknown column 't1.id' in field list—— 这说明你写了相关子查询但没加外层表别名引用，或者解析器根本没把它识别为相关子查询 - 非相关子查询（如
WHERE id IN (SELECT id FROM cities WHERE country = 'CN')）会被优化器物化一次，结果缓存复用 - 相关子查询（含
t1.x这类外层列）则每行触发一次，性能风险极高，容易引发 N+1 问题 - 优化器可能将部分
IN/EXISTS重写为半连接（semi-join），但不能依赖；要看EXPLAIN输出中Extra字段是否出现Using where; Using join buffer
标量子查询（返回单值）常被优化为常量传播
SELECT name, (SELECT MAX(created_at) FROM logs) AS latest_log FROM users 这类子查询，只要不依赖外层字段，优化器通常会在计划生成阶段就把它算出来，变成一个固定值参与后续计算。
- 如果子查询里用了聚合 +
GROUP BY或窗口函数，就无法提前物化，必须等执行时动态求值 - 若标量子查询返回空（
NULL），外层表达式会按三值逻辑处理：比如WHERE status = (SELECT ...)遇到NULL就整行被过滤掉 - MySQL 8.0+ 支持
LATERAL关键字显式声明相关性，可提升可读性和优化空间，但不是所有版本都支持
NOT IN 和 EXISTS 的行为差异本质不在执行顺序，而在语义
NOT IN 遇到子查询结果含 NULL 会整体返回空结果，这不是执行卡住了，而是 SQL 三值逻辑（true/false/unknown）的必然结果；而 EXISTS 只关心是否存在，天然短路，不构造结果集。
-
WHERE x NOT IN (SELECT y FROM t WHERE ...)等价于WHERE x != y1 AND x != y2 AND ... AND x != NULL→ 整个条件变为 unknown → 被过滤 -
WHERE NOT EXISTS (SELECT 1 FROM t WHERE t.y = x)不受NULL影响，语义清晰、性能可控 - 即使子查询本身很快，
NOT IN在有NULL时仍会导致意外空结果，这是最容易被忽略的语义陷阱
嵌套查询不等于逻辑执行顺序里的“WHERE 阶段之后”
SQL 标准定义的逻辑处理阶段是 FROM → WHERE → GROUP BY → SELECT，但嵌套查询属于“表达式求值”，它在语义分析阶段就被提前调度——也就是说，WHERE 里的子查询，其执行权优先级高于 FROM 主表的实际数据读取。
- 物理执行起点是
FROM，但子查询是逻辑前置动作；你可以理解为：数据库先画好“判断依据的草图”，再决定怎么读主表 - 多层嵌套（如
WHERE a IN (SELECT b FROM t1 WHERE b IN (SELECT c FROM t2))）一定是从最内层开始，逐层向上归并结果 - 子查询中禁止
ORDER BY（除非配合LIMIT或用于窗口函数上下文），因为关系代数不要求中间结果有序；加了也不报错，但会被忽略
真正复杂的地方在于：你以为的“自内向外”只是逻辑保证，实际执行路径完全由优化器根据统计信息、索引、数据分布动态决定。同一个嵌套查询，在不同数据量或配置下，可能走物化临时表，也可能转成哈希连接，甚至被完全消除——所以永远以 EXPLAIN 输出为准，而不是凭经验猜。
