SQL解析器仅做词法分析（拆分token）和语法分析（构建AST），不查表、不验权限、不访问元数据；ERROR 1064即其报错，如关键字拼错、缺逗号、括号不匹配等导致AST无法生成。
SQL解析器只做两件事：拆词、验语法
解析器不查表、不验权限、不看数据，它只负责把一串字符变成结构化的树。你写错一个关键字、少个逗号、括号不匹配，它就立刻报错，比如ERROR 1064 (42000)。这个阶段根本没碰数据库元数据，纯粹是字符串层面的规则校验。
具体分两步：
- 词法分析：把
SELECT name FROM users WHERE id = 1切分成SELECT、name、FROM、users等 token，每个 token 标记类型（关键字/标识符/常量） - 语法分析：按 MySQL 语法规则组装成抽象语法树（AST），确认是不是合法的 SELECT 语句结构——比如不能有
SELECT ... FROM ... ORDER BY却没LIMIT在子查询里，这种结构在语法上就不被允许
一旦 AST 构建失败，流程立刻终止，后续步骤根本不会触发。
预处理器才是真正在“查系统”
预处理器拿到解析器产出的 AST 后，才真正开始访问数据库内部状态。它不是优化器，也不决定怎么执行，但它必须确保“这句话在当前环境下能跑起来”。常见失败点都在这一步：
-
Table 'test.users' doesn't exist：查information_schema.tables或 InnoDB 数据字典，发现表不存在 -
Unknown column 'namee' in 'field list'：字段名拼错，或列确实不在该表中（注意：视图展开后也会在这步校验底层列） -
SELECT command denied to user：权限检查——哪怕连接器认证通过了，这里仍会查该用户对users表是否有SELECT权限 - 遇到
SELECT *时，会在这里展开成实际列名列表，供后续优化器使用
MySQL 8.0 起用 InnoDB 存储的数据字典替代了旧的 .frm 文件，所以预处理器查的是真实引擎里的元数据，不是文件系统快照。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
为什么这两个阶段不能合并？
分离的核心目的是解耦和容错。解析器快、轻量、纯内存操作；预处理器慢、依赖 I/O、可能触发锁或等待。如果把权限和对象检查塞进解析器，那每次语法错误都要先查一遍字典，性能雪崩。更关键的是：某些语法本身合法但语义非法（比如引用了还没创建的临时表），必须留到预处理阶段才能判断。
典型反例：SELECT * FROM non_existent_table 会顺利过解析器，但在预处理器报错；而 SELCT * FROM users（SELCT 拼错）连解析器都过不去，直接返回 1064 错误。
容易被忽略的细节：预处理器也处理别名和视图
别名不是语法糖，它在预处理阶段就被绑定到具体对象。例如 SELECT u.name FROM users AS u，这里的 u 会被替换成 users 的内部指针；如果写成 SELECT u.name FROM (SELECT id, name FROM users) AS u，预处理器还要递归展开子查询并验证字段存在性。
视图同理：预处理器会把 SELECT * FROM v_users 中的 v_users 替换为其定义 SQL，并对那个定义再次走一遍解析 + 预处理流程——这意味着视图定义里有错，错误位置会指向视图本身，而不是调用它的那条语句。
