MySQL 的 SQL 语义分析发生在语法分析之后、查询优化之前的解析阶段后期。它检查表名、列名、函数、权限等逻辑合法性，不验证数据内容，失败则报错如 ER_BAD_FIELD_ERROR（1054）等。
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 顺序，先确认表名、列名、函数名、库权限这四样东西拼写和上下文都对得上。
