MySQL 的 SQL 语法分析发生在哪个阶段
MySQL 在执行一条
SELECT、
INSERT等语句时，会先经过「解析器（Parser）」进行语法分析，这是整个查询生命周期的第一步。它不检查表是否存在、字段有没有权限，只确认 SQL 字符串是否符合 MySQL 自己的语法规则。
这个阶段失败，你会看到典型的错误：
ERROR 1064 (42000): You have an error in your SQL syntax。比如少了个括号、关键字拼错、引号不闭合，都会在这里被拦截。
常见触发语法分析失败的写法
这些写法不会进入优化器或执行器，连表名校验都走不到：
SELECT * FROM users WHERE id = ;——
=后面缺值
SELEC * FROM users;—— 关键字
SELECT拼错
SELECT name, age FROM users ORDER BY;——
ORDER BY后没跟字段
SELECT 'hello world—— 单引号没闭合，字符串字面量非法
CREATE TABLE t (id INT, name VARCHAR(20) NOT NULL DEFAULT);——
DEFAULT后缺默认值
如何验证语法是否通过（不真正执行）
MySQL 本身没有类似
EXPLAIN FORMAT=TREE那样直接“预检语法”的命令，但有几种实用方式： 在客户端里粘贴语句后按回车，如果报
ERROR 1064就是语法不过关 用
mysql --force连接，它会在出错时继续执行下一条，适合批量检查脚本 在应用层（如 Python 的
mysql-connector或 Go 的
database/sql）捕获
1064错误码来做前置校验 使用
PREPARE stmt FROM '...';—— 如果语法错，
PREPARE会直接失败，且不产生临时执行计划
注意：
EXPLAIN SELECT ...虽然常用来看执行计划，但它**必须先通过语法分析**，所以也能间接帮你发现语法问题；但如果语句本身语法合法但语义错误（比如表不存在），
EXPLAIN会报另一个错误（
ERROR 1146），不是 1064。
语法分析和词法分析的区别在哪
MySQL 内部其实分两步：先「词法分析（Lexical Analysis）」把输入流切分成 token（比如
SELECT、
`id`、
123、
=），再「语法分析（Syntax Analysis）」按语法规则（Bison 生成的 LALR(1) 解析器）组装成抽象语法树（AST）。
你遇到的绝大多数
1064错误，其实是语法分析阶段失败；而词法分析失败更少见，例如输入了 MySQL 不识别的字符（如某些 Unicode 控制符），或者用了未加反引号的保留字当标识符但没转义（
order当列名却不写成
`order`）。
真正写业务 SQL 时，几乎不需要关心 AST 结构，但得知道：只要没过这关，后续所有优化、权限检查、引擎调用全都不会发生。
SELECT COUNT(*) AS cnt FROM orders WHERE status = 'shipped' AND created_at > '2024-01-01';
上面这段语句能通过语法分析，不代表它能执行成功——如果
orders表不存在，错误会出现在下一步（语义分析），报的是
ERROR 1146，不是
1064。
语法分析只管“像不像话”，不管“存不存在”“有没有权限”“会不会超时”。这点容易混淆，尤其在调试慢查询或部署脚本时，要先分清错误类型再往下查。
