SQL语句首先进入解析器（Parser），它在连接器认证后立即进行词法和语法分析，检查关键字、标识符、运算符及语法规则顺序，错误如SELECT FROM user会在此报ERROR 1064。
SQL语句一进来，先被谁“看”？——连接器之后就是解析器
MySQL 接收一条 SQL 后，并不是直接执行，而是先走一遍「解析流水线」。真正第一个对 SQL 做结构化检查的模块是 Parser（解析器），它在连接器完成认证、会话建立后立即介入。
这个阶段干两件事：词法分析（把 SELECT * FROM user WHERE id = 1 拆成关键字、标识符、运算符等 token）和语法分析（按 MySQL 语法规则校验顺序是否合法）。一旦出错，比如写成 SELECT FROM user 缺少字段列表，或 WHERE 放在 GROUP BY 前面，错误就在这里抛出：ERROR 1064 (42000): You have an error in your SQL syntax。
- 语法检查严格遵循固定顺序：
FROM→JOIN→ON→WHERE→GROUP BY→HAVING→SELECT→DISTINCT→ORDER BY→LIMIT - 大小写敏感：缓存和解析都区分大小写，
select * from t和SELECT * FROM T被视为两条不同语句 - 注释会影响解析：多行注释
/* */若未闭合，会导致后续 SQL 被吞掉，报错位置可能远偏离实际问题行
解析完还不算完——预处理器要再过一遍语义
解析器生成的是语法树（parse tree），但还不能保证语义正确。Preprocessor（预处理器）紧接着上场，做更深层验证：表是否存在、字段名是否拼错、别名是否冲突、权限是否足够访问目标列等。
比如你写了 SELECT name, age FROM users，但 users 表根本不存在，或者 age 字段实际叫 user_age，这个错误不会在解析器报，而是在预处理阶段触发：ERROR 1146 (42S02): Table 'db.users' doesn't exist 或 ERROR 1054 (42S22): Unknown column 'age' in 'field list'。
- 预处理会查
information_schema元数据，所以表结构变更后，旧连接里缓存的表定义可能未刷新（长连接场景下尤其要注意） - 如果用了视图或子查询，预处理器还会递归展开并校验嵌套层级中的对象合法性
-
SQL_MODE设置影响预处理行为：开启STRICT_TRANS_TABLES时，隐式类型转换失败会直接报错，否则可能静默截断
为什么有时候改个空格就报错？——解析器对格式极其敏感
MySQL 解析器不是“智能容错”的，它依赖明确的分隔和结构。很多看似无关的格式问题，实则是解析器无法生成合法语法树导致的。
- 字符串里混用引号：
WHERE name = "O'Reilly"如果没转义单引号，会被截断为WHERE name = "O'，后续内容变成非法 token - 数字字面量带前导零：
WHERE id = 010在某些 SQL_MODE 下被当八进制解析，值变成 8，逻辑出错但不报错——这是语义陷阱，非解析错误 - 使用保留字作标识符但没加反引号：
SELECT order FROM t中order是保留字，必须写成SELECT `order` FROM t，否则解析失败 - 换行与注释干扰：在存储过程中动态拼 SQL 时，若用
CONCAT拼接含换行的字符串，可能意外引入不可见字符，导致解析中断
缓存、优化器、执行器……它们都不参与语法解析
很多人误以为「查询缓存命中就跳过解析」，其实不对。MySQL 8.0 已彻底移除查询缓存（query_cache_type=OFF 默认且不可启用），而即使在 5.7 及以前，缓存也只在解析+权限校验之后才检查——也就是说，语法错误永远无法被缓存绕过。
同样，Optimizer 不改语法结构，只基于合法解析树选索引和连接顺序；Executor 更只是按执行计划调用引擎接口。真正决定「这条 SQL 能不能活到执行那一步」的，只有解析器和预处理器。
- 想快速验证语法是否合法？不用跑真实查询，用
EXPLAIN FORMAT=TREE或EXPLAIN EXTENDED（5.7）可触发完整解析流程并返回执行计划，失败则直接报错 - 开发期建议在客户端工具里开启「语法高亮 + 实时校验」，比如 DBeaver 或 VS Code 的 MySQL 插件，能提前暴露大部分解析级问题
- 上线前用
mysql --force -e "your_sql"测试脚本，--force让错误不中断后续语句，方便批量发现语法硬伤
解析阶段不出错，不代表逻辑正确；但解析阶段一出错，后面所有环节都轮不到——这是最硬的一道关卡，也是最容易被日志忽略的源头。
