mysql解析阶段不执行子查询，只构建语法树并标记子查询类型及依赖关系：解析器识别子查询嵌套层级、判断是否相关（如引用外层列）、记录作用域和别名，但不校验表或字段是否存在，也不执行任何逻辑。
MySQL解析阶段不执行子查询，只做语法树构建和依赖分析
MySQL在SQL解析阶段（即parse phase）根本不会运行任何子查询逻辑，它只负责把整条SQL拆解成一棵语法树（parse tree），并标记出哪些节点是子查询、它们嵌套在哪一层、是否引用了外层表的列。这个阶段连表是否存在、字段名对不对都还没校验——那些是后续的语义分析（semantic analysis）和优化器（optimizer）阶段的事。
关键点在于：子查询是否“相关”，是在解析阶段就初步判定的。比如 WHERE salary > (SELECT AVG(salary) FROM employees WHERE department_id = e.department_id) 中的 e.department_id 明确引用了外层别名 e，解析器会直接打上 dependent subquery 标记；而 (SELECT MAX(id) FROM logs) 这种无外部引用的，会被标记为 uncorrelated subquery。
- 解析器不检查子查询里的表或字段是否存在——哪怕写成
(SELECT xxx FROM non_existent_table)，也能通过解析 - 子查询的括号层级、逗号分隔、AS别名写法（如
(SELECT ...) AS t）必须符合语法，否则直接报ERROR 1064 - MySQL 8.0+ 在解析时会额外记录子查询类型（标量/行/列/表），影响后续物化策略选择
为什么EXPLAIN看到的select_type是"DEPENDENT SUBQUERY"而不是"SUBQUERY"
EXPLAIN 输出中的 select_type 字段反映的是优化器阶段的决策结果，不是解析阶段的原始标记。解析阶段只划出“有依赖”或“无依赖”，但最终归类为 DEPENDENT SUBQUERY 还是 MATERIALIZED 或 DERIVED，取决于优化器是否启用半连接、物化、表拉出（table pullout）等策略。
常见混淆点：IN 子查询在 MySQL 5.6+ 默认触发 semi-join 优化，EXPLAIN 可能显示 select_type=PRIMARY 而非 DEPENDENT SUBQUERY，但这不改变原始SQL被解析为相关子查询的事实——只是优化器重写了执行路径。
- 若子查询含
ORDER BY + LIMIT（如分页子查询），即使无外层引用，也可能被强制标记为DEPENDENT SUBQUERY，因为结果集不可缓存 -
EXISTS子查询几乎总是DEPENDENT SUBQUERY，除非优化器能将其转换为 semi-join - 使用
EXPLAIN FORMAT=JSON才能看到底层是否启用"semi-join": "firstmatch"等真实优化行为
子查询别名和列名在解析阶段就绑定作用域
子查询里的 AS 别名（如 (SELECT id, name FROM users) AS u）在解析阶段就确定了作用域边界：外层查询无法直接引用 u.id，除非显式 JOIN 或在 FROM 中作为派生表；而子查询内部若引用同名字段（如外层也有 id），解析器会按就近原则绑定，不会跨作用域查找。
这解释了为什么这类写法会报错：SELECT * FROM orders WHERE id IN (SELECT id FROM customers) —— 解析器发现子查询中 id 未指定表前缀，且 customers 表里没有 id 字段（只有 customer_id），此时错误发生在语义分析阶段，而非解析阶段。
-
FROM子句中的子查询必须带别名，否则解析直接失败：ERROR 1248 -
SELECT列表里的标量子查询（如(SELECT COUNT(*) FROM logs WHERE user_id = o.id)）中，o.id的绑定在解析时完成，后续优化器才决定是否对每行重执行 - 子查询内不能用外层定义的用户变量（如
@x），解析器会报ERROR 1242，因为变量作用域不穿透子查询边界
真正影响性能的环节不在解析阶段，而在执行计划生成
解析快慢几乎可以忽略——耗时微秒级。真正卡住查询的，是优化器对子查询执行策略的选择：是否物化、是否转为 join、是否启用 loosescan、临时表用内存还是磁盘。这些决策基于统计信息、索引可用性、optimizer_switch 设置，与解析无关。
所以当你看到一条嵌套查询慢，不要去查“解析花了多久”，而该看 EXPLAIN 的 Extra 列：Using temporary 表示物化开销大，Using where; Using index 表示索引有效，Start transaction 类提示则说明可能触发了不必要的锁等待。
- 解析阶段无法绕过，但你可以绕过它的限制：用 CTE 替代深层嵌套，MySQL 8.0+ 的 CTE 在解析时被展开为独立子查询节点，更利于优化器重排
- 避免在子查询里写
SELECT *，解析器虽不报错，但会把所有字段带入后续计划，增加元数据开销 - 如果子查询返回结果集过大（如百万行），解析没问题，但物化时可能超出
tmp_table_size，导致磁盘临时表——这才是性能断崖点
