MySQL的SQL语法分析发生在解析器阶段，即查询生命周期的第一步，仅验证SQL字符串是否符合语法规则，不检查表存在性或权限，失败时抛出ERROR 1064。
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 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
语法分析和词法分析的区别在哪
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。
语法分析只管“像不像话”，不管“存不存在”“有没有权限”“会不会超时”。这点容易混淆，尤其在调试慢查询或部署脚本时，要先分清错误类型再往下查。
