MySQL分析器仅做词法和语法检查，输出语法树，不查表、不验权限；ERROR 1064即其报错，如ORDERY BY或漏引号，此时未进入优化或执行阶段。
分析器只做词法和语法检查，不查表、不验权限
MySQL分析器（parser）本质是个“文本翻译工”，它拿到的是原始SQL字符串，输出是一棵语法树（parse tree），仅此而已。它不访问数据字典，不确认users表是否存在，也不管当前用户有没有SELECT权限——这些都留给后续的预处理器和访问控制模块。
常见错误现象：ERROR 1064 (42000) 就是分析器报的，比如把 ORDER BY 手误写成 ORDERY BY，或者漏了引号：WHERE name = zhangsan（未加单引号），分析器在词法切分时就卡住，根本不会进入优化或执行阶段。
- 词法分析：把
SELECT * FROM t WHERE id = 1拆成 token 序列：SELECT（关键字）、*（通配符）、FROM（关键字）、t（标识符）、WHERE（关键字）、id（标识符）、=（操作符）、1（数字字面量） - 语法分析：按 MySQL 语法规则组装节点，生成树形结构；
id = 1被记为一个Item_func_eq节点，但此时不计算、不查字段类型、不判断id是否真在表里 - 表达式不求值：
SELECT a + b * 2 FROM t中的a + b * 2只存为表达式节点，连a和b是不是合法列名都不管
语法树不是执行计划，也不含索引或性能信息
很多人看到 EXPLAIN 输出就以为那是分析器干的，其实完全不是一回事。分析器输出的语法树是纯结构描述，比如 SELECT name FROM users WHERE age > 18 的语法树里只有“有一个WHERE子句”“条件是大于比较”这类信息，没有“用哪个索引”“要不要排序”“是否能下推”等任何执行策略。
真正决定怎么查的是优化器，它拿语法树去查元数据、评估成本、重写查询（比如把 IN 改成 EXISTS），最后生成带访问路径的执行计划（query execution plan）。分析器连表结构长什么样都不知道，更不可能参与索引选择。
-
EXPLAIN显示type: ALL或type: ref，这些是优化器决策结果，和分析器无关 - 即使语法树正确，后续仍可能失败：预处理器发现表不存在 →
ERROR 1146 (42S02)；优化器找不到可用索引 → 执行变慢但不报错 - 语法树里不记录字符集、排序规则、字段精度等语义细节，那些由存储引擎层或执行器后期处理
为什么改个空格或大小写有时就解析失败
MySQL分析器对关键字大小写不敏感（select 和 SELECT 一样），但对字符串字面量、标识符的引号和边界极其敏感。问题往往出在不可见字符或上下文歧义上。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
典型场景：SELECT * FROM `user` WHERE created_at >= '2023-01-01 00:00:00' 如果末尾多了一个全角空格或零宽字符，词法分析器可能把时间字符串截断，导致解析失败；又比如 GROUP BY user.id 中的点号被误认为小数点，而 user.id 又没被识别为合法标识符组合，也会触发 ERROR 1064。
- 避免用保留字作别名，如
SELECT name AS order FROM t→ 解析器会把order当成关键字，报错 - 用反引号包裹含特殊字符的标识符：
`my-table`、`order by`，否则解析直接中断 - 时间字面量必须严格符合格式，
'2023/01/01'在 strict 模式下可能被拒绝，不是语法错误而是后续校验阶段的事
调试解析失败，优先看 ERROR 1064 的位置提示
当遇到 ERROR 1064，MySQL 通常会在错误信息末尾标出出错位置，例如：You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'ORDERY BY name' at line 1。这个“near”后面的内容就是分析器最后成功识别的 token，之后的部分它无法归类。
实操建议不是去翻文档猜语法，而是复制报错 SQL 到最小可复现片段，逐段删减。比如整条语句报错，先去掉 ORDER BY，再试；如果还错，再砍掉 WHERE；直到剩下 SELECT * 都通不过，基本就是开头有 BOM 或隐藏控制符。
- 用
hexdump -C或编辑器的“显示不可见字符”功能检查 SQL 文件是否有 UTF-8 BOM - 在 MySQL 客户端里用
SELECT HEX('your_sql_part');看实际传入的字节序列 - 避免从富文本编辑器（如 Word、微信）直接复制 SQL，容易混入全角标点或换行符
解析器这一步看着简单，但它卡住的地方往往最隐蔽——没有日志、不写 binlog、不占执行时间，只丢一个模糊的语法错误。真正难调的不是慢查询，而是连解析都过不去的那条语句。
