mysql词法分析器将sql字符串按规则切分为原子token：跳过空白符，识别关键字、标识符、字面量、运算符等；反引号包裹内容整体为标识符，漏闭合则直接报error 1064。
MySQL词法分析器怎么切分SQL字符串
MySQL服务端收到SQL文本后，第一件事不是理解语义，而是“断词”——把一整条 SELECT * FROM users WHERE age > 25 拆成 SELECT、*、FROM、users、WHERE、age、>、25 这样的原子单元（Token）。这个过程不关心字段是否存在、表有没有权限，只认字符模式。
它依赖内置的词法规则表：比如连续字母+下划线开头的非关键字字符串被识别为标识符；123、'hello'、NULL 各自匹配数字、字符串、空值字面量；=、!=、BETWEEN 等硬编码为运算符或保留字。空格、换行、制表符全被跳过，所以 SELECT\nname FROM\tusers 和紧凑写法效果一样。
常见踩坑点：
- 反引号包裹的标识符（如
`order`）会被整体识别为一个标识符 Token，避免和关键字冲突；但若漏写闭合反引号，词法分析直接失败，报错类似ERROR 1064 (42000): You have an error in your SQL syntax，且位置提示往往不准——因为还没到语法校验阶段 - 注释处理发生在词法层：单行注释
--和#后内容被丢弃；多行注释/* ... */内容也被跳过，但注意/*+ */这类优化器提示会被保留为特殊 Token - 客户端传入的参数化查询（如
SELECT * FROM t WHERE id = ?）中，?被识别为占位符 Token，而非语法错误——这是预处理阶段才替换的，词法层只管“这是个问号”
语法分析器如何验证Token序列是否合法
词法分析输出的 Token 序列交给语法分析器（基于 Bison 生成的解析器），它对照 MySQL 官方定义的上下文无关文法（CFG）做匹配。比如 SELECT 开头的语句，必须后接字段列表、FROM 子句，再可选 WHERE/GROUP BY 等——顺序、嵌套、可选性都由文法规则严格约束。
一旦 Token 序列无法匹配任何一条产生式规则，就立刻报错，例如：
-
SELECT name FROM users WHERE;——WHERE后缺表达式，语法树无法闭合 -
UPDATE users SET name = 'a' WHERE id = 1 ORDER BY name;——UPDATE语句不允许ORDER BY（除非配合LIMIT），文法中没定义该结构 -
SELECT * FROM t1 JOIN t2 ON t1.id = t2.uid USING (id);——ON和USING互斥，语法分析器拒绝同时出现
此时报错信息里的 “near …” 提示通常比词法错误更准，因为它已尝试按文法展开推导，卡在某个非终结符处。
词法/语法分析失败时，错误发生在哪一层
关键判断依据是错误信息中是否提及具体 Token 或位置偏移。如果报错含 near 'xxx' 或明确指出第 N 个 Token 不合法，基本是语法分析失败；如果报错模糊如 Unknown character '\x9f' 或直接中断在某行某列未识别字符，则大概率是词法分析卡住。
实际调试建议：
- 用
mysql --verbose连接，执行语句时会打印解析前原始输入，确认客户端没做意外转义（比如 Python 的%格式化误把%s当 SQL 占位符） - 检查字符集：服务端
character_set_client和连接时声明的编码不一致时，某些 Unicode 字符可能被截断成非法字节，导致词法分析器看到乱码 Token - 禁用查询缓存（
SET SESSION query_cache_type = OFF）再试——极少数旧版 MySQL 中缓存污染会导致解析器读到损坏的内部结构
为什么不能跳过词法/语法分析直接执行
因为 MySQL Server 层所有后续模块（预处理、优化器、执行器）都依赖语法分析输出的解析树（Parse Tree）。这棵树不是简单字符串，而是带节点类型、子节点引用、位置信息的内存结构。没有它，优化器无法知道 WHERE 条件在哪、字段属于哪张表；执行器无法区分 SELECT 和 INSERT 的操作意图。
这意味着：哪怕你确定 SQL 逻辑正确，只要有一个标点符号错位（比如漏了逗号、多打了括号），整个请求就在分析器这步终止，根本不会走到权限检查或存储引擎——这也是为什么线上遇到 ERROR 1064 时，第一反应永远是检查 SQL 文本本身，而不是查表是否存在或用户有没有权限。
真正容易被忽略的是：词法与语法分析全程在内存中完成，不访问磁盘、不查数据字典、不触发任何锁。所以它们极快，但也意味着——出错反馈是纯粹的“文本病”，和数据库运行状态无关。
