mysql词法分析器对长sql采用单次正向扫描，遇嵌套括号、未闭合引号或深层注释时会触发回溯，时间复杂度从o(n)退化为o(n²)，导致数十毫秒延迟；超长sql还加剧语法树构建、预处理字符串展开及字符集校验开销，且慢日志可能不记录该阶段耗时。
MySQL词法分析器对长SQL的线性扫描开销
MySQL在收到SQL后，第一步是词法分析（Lexer），把原始字符串切分成一个个token（如SELECT、FROM、标识符、字符串字面量等）。这个过程本质上是**单次正向遍历**，但遇到嵌套括号、引号包裹的复杂字符串（比如JSON字段值、长注释、超长IN列表）时，解析器必须逐字符匹配边界，无法跳过。一旦SQL文本长度超过几万字符，仅这一步就可能消耗数十毫秒——尤其当存在未闭合引号或嵌套层级过深时，还会触发回溯匹配，时间复杂度从O(n)退化为O(n²)。
深层子查询和UNION嵌套加剧语法树构建压力
超长SQL往往伴随多层子查询、大量UNION ALL拼接或动态生成的条件分支。MySQL的语法分析器会为每个子查询构造独立的解析树节点，并在后续优化阶段反复合并、裁剪。当EXPLAIN输出中出现多个DERIVED或UNION类型的select_type，且id值深度大于5时，说明语法树已非常臃肿。此时即使语义简单（比如只是拼了100个SELECT 1），构建和验证这棵树的内存分配、指针链接、作用域检查成本也会陡增。
预处理阶段的字符串替换与参数绑定放大延迟
很多超长SQL来自ORM拼接或前端传入的动态条件（如WHERE id IN (1,2,3,...,10000)）。如果应用层未做参数化，而是直接字符串拼接，MySQL就必须在解析前完成全部文本展开。更隐蔽的问题是：某些客户端驱动（如旧版mysql-connector-python）会在发送前自动将?占位符替换成实际值并转义，导致SQL体积极速膨胀。这时你看到的SHOW PROCESSLIST里状态可能是init或checking permissions，实际卡在服务端的输入缓冲区解析环节。
容易被忽略的字符集与注释陷阱
以下情况会让解析耗时非线性上升，却很难被EXPLAIN暴露：
- SQL开头含大量UTF-8 BOM或不可见控制字符（如
\u200B零宽空格），Lexer需额外逻辑过滤 -
/* */块注释嵌套或跨行未闭合，解析器会持续扫描直到文件末尾或下一个*/ - 使用
SET NAMES utf8mb4后，但SQL中混入了未转义的emoji或四字节字符，触发字符边界重校验
这类问题在慢日志里通常不体现为“执行慢”，而是根本没走到执行器——slow_query_log甚至不会记录它，因为卡在连接器之后、优化器之前。
