MySQL分析器仅做词法和语法检查并输出语法树，不查表、不验权限；ERROR 1064即其报错，如ORDERY BY或漏引号，此时未进入优化或执行阶段。
MySQL本身不暴露词法/语法解析阶段的独立耗时数据，你无法直接查到“词法分析花了多少微秒”或“语法树构建用了多久”。这两个阶段属于解析器内部快速执行的固定流程，MySQL未提供对应指标或钩子。真要定位这类问题，得换思路：看错误类型、复现条件、绕过缓存强制重解析。
词法分析失败时，错误发生在哪一层
词法分析失败会直接中断整个SQL处理流程，错误信息明确指向“非法字符”或“无法识别的token”。典型表现是客户端收到类似 ERROR 1064 (42000): You have an error in your SQL syntax 的报错，但注意——这个错误码其实覆盖了词法和语法两层问题。
- 真正纯词法失败（比如输入了不可见控制字符、UTF-8 BOM头、混入零宽空格）通常表现为：错误位置提示为第一个非空白字符，且
sql_state是42000，但错误消息里不提具体关键字，只说 near '' 或 near '' - 如果错误消息里明确写出 near 'SELECT' 或 near 'WHERE id = '，那大概率已通过词法分析，卡在语法分析阶段
- 用
hex()或HEX(SUBSTR(@sql, pos, 1))检查可疑位置的字节值，能快速确认是否混入非法字节
语法分析阶段无法单独计时，但可触发重解析验证
语法分析本身不耗资源，但它是后续所有阶段的前提。如果你怀疑某条SQL反复触发语法分析（比如没走查询缓存、预处理语句被频繁重编译），可以用以下方式间接观察：
- 关闭查询缓存：
SET SESSION query_cache_type = OFF，再执行同一条SQL多次，用SHOW PROFILE查看每次的parse阶段耗时是否稳定（MySQL 5.7+ 支持，8.0 默认禁用该命令，需先设SET profiling = 1） - 对预处理语句（
PREPARE stmt FROM ...）重复执行EXECUTE stmt，对比首次和后续执行的parse耗时——首次应有 parse，后续应为 0 - 若发现
parse耗时波动大，优先检查客户端是否每次都传了不同字符串（比如带了动态注释、随机空格、时间戳拼接），导致 MySQL 认为是新SQL而非重用
为什么 SHOW PROFILE 的 parse 时间不准或缺失
SHOW PROFILE 中的 parse 阶段实际包含词法 + 语法 + 部分预处理（如列名展开），不是原子操作。更重要的是：
- MySQL 8.0 默认关闭 profiling 功能，启用需手动设
SET profiling = 1，且仅对当前 session 有效 - 当 SQL 命中查询缓存（5.7 及更早）时，
parse阶段会被跳过，SHOW PROFILE显示为空或 0 - 如果 SQL 很短（如
SELECT 1），parse 时间可能低于 profiler 的最小采样精度（微秒级），显示为 0 - 真正想测解析开销，应该用压测工具（如 sysbench）跑固定 SQL 模板，统计端到端 P99，并对比开启/关闭
query_cache_type的差异
词法与语法解析本身几乎不构成性能瓶颈，但它们是整个SQL执行链路的第一道过滤器。一旦出错，问题一定出在SQL文本源头——要么是客户端生成逻辑有缺陷，要么是ORM/驱动做了隐式改写，要么是运维配置了错误的字符集或SQL mode。盯住错误信息里的 near 位置和原始字节，比纠结“耗时多少”更能快速归因。
