MySQL 的 SQL 语义分析发生在哪个阶段
MySQL 在执行一条 SQL 前，会经历
词法分析 → 语法分析 → 语义分析 → 查询优化 → 执行计划生成这一准备链路。语义分析不是独立模块，而是嵌套在
parse（解析）阶段后期、
optimize（优化）阶段前期的关键检查环节。
它不验证数据内容，只确认「SQL 写的有没有逻辑矛盾」：比如引用的表是否存在、列名是否拼错、函数参数个数是否合法、权限是否足够、别名是否冲突等。一旦失败，报错如
Unknown column 'xxx' in 'field list'或
Table 'db.xxx' doesn't exist，就大概率卡在语义分析环节。
常见语义错误及对应报错特征
这些错误通常在
PREPARE阶段或首次
EXECUTE时触发，而非运行时：
Unknown table 't1'：FROM 子句中表未声明或数据库名/权限不对
Unknown column 'a.b' in 'where clause'：列名带非法前缀，或别名作用域越界（如在 WHERE 中引用 SELECT 列别名）
Function 'json_extract' does not exist：函数名拼写错误，或 MySQL 版本低于 5.7（该函数引入版本）
Column 'id' in field list is ambiguous：多表 JOIN 时未用表前缀限定同名列
Access denied for user ... to database 'xxx'：语义层已识别目标库，但权限校验失败
如何观察语义分析是否通过
MySQL 不暴露语义分析中间状态，但可通过以下方式间接判断：
启用general_log = ON，看日志中是否出现
Prepare记录而无后续
Execute—— 表示卡在准备阶段 对预处理语句使用
SHOW WARNINGS，部分语义错误会转为 Warning 级别提示 在低权限账号下执行
EXPLAIN FORMAT=TRADITIONAL SELECT ...：若直接报错而非返回执行计划，说明未通过语义检查 注意错误码：语义类错误多为
ER_BAD_FIELD_ERROR（1054）、
ER_NO_SUCH_TABLE（1146）、
ER_ACCESS_DENIED_ERROR（1045）等
语义分析与查询重写的关系
MySQL 在语义分析后、优化器介入前，会做一次隐式重写（rewrite），这步依赖语义正确性。例如：
SELECT * FROM t1 WHERE id = 1 AND 1 = 1;
会被重写为：
SELECT * FROM t1 WHERE id = 1;
但如果原始语句存在语义错误（如
WHERE nonexist_col = 1），重写根本不会发生——因为连“
nonexist_col是什么”都未能绑定到任何对象。
这意味着：你看到的执行计划（EXPLAIN 输出）一定已经通过了语义分析；反之，只要没走到 EXPLAIN，问题就出在词法、语法或语义任一前置环节。
实际调试时，别急着调索引或改 JOIN 顺序，先确认表名、列名、函数名、库权限这四样东西拼写和上下文都对得上。
