mysql中的SQL语句解析与执行流程

4次阅读

MySQL 解析 SQL 先经 parse_sql()递归下降分析,生成语法树;优化器重写逻辑并生成执行计划;执行器调用存储引擎接口读取数据,期间处理锁、事务可见性与权限校验。

mysql 中的 SQL 语句解析与执行流程

MySQL 如何解析一条 SQL 语句

MySQL 不是直接执行你写的 SQL 字符串,而是先把它拆解成内部可理解的结构。这个过程叫「解析(parsing)」,核心是 sql_parse.cc 里的 parse_sql() 函数。它用的是自顶向下递归下降语法分析器,基于预定义的 sql_yacc.yy 语法文件生成词法和语法树。

常见卡点:如果 SQL 里有不支持的语法(比如 MySQL 5.7 里写 JSON_EXTRACT(json_col, '$.a.b') 没问题,但 -> 操作符要 8.0+),解析阶段就直接报错ERROR 1064 (42000),根本进不了后续流程。

  • 注释、空格、大小写在解析阶段被剥离,SELECT * FROM tselect*fromt 最终生成的解析树几乎一样
  • 反引号包裹的标识符(如`order`)会被保留为合法列名,避免和关键字冲突
  • 未加引号的字符串字面量(如WHERE name = abc)会被当作列名处理,导致Unknown column 'abc' in 'where clause'

查询优化器怎么改写你的 SQL

解析完得到语法树后,优化器(optimizer)开始工作。它不信任你写的 SQL 顺序,会重排表连接顺序、下推条件、消除冗余字段——这些动作统称「逻辑重写」。关键入口是 optimize_cond()make_join_statistics()

典型现象:你写 SELECT * FROM a JOIN b ON a.id = b.a_id WHERE b.status = 'active',优化器可能把WHERE 条件提前到 b 表扫描时过滤,甚至改用 IN (SELECT ……) 等价重写(取决于统计信息是否准确)。

  • 使用 EXPLAIN FORMAT=TREE 能看到优化器实际选择的执行计划树,比传统 EXPLAIN 更直观
  • SET optimizer_switch='derived_merge=off'能禁用派生表合并,用于调试复杂子查询行为
  • 统计信息过期(ANALYZE TABLE没跑)会导致优化器误判索引选择,出现本该走索引却全表扫描

执行器真正干活时依赖哪些数据结构

优化器输出执行计划后,执行器(executor)按节点逐个调用 ha_xxx::index_read()ha_xxx::rnd_next()接口读取数据。每张表对应一个 TABLE 结构体,其中 file 成员指向存储引擎的具体实现(如ha_innobase)。

注意:执行阶段才真正触发锁、事务可见性判断、权限校验。比如 SELECT 在 RR 隔离级别下,执行器会根据 read_view 决定某行是否对当前事务可见——这和解析、优化完全无关。

  • 临时表(CREATE TEMPORARY TABLE)只在当前连接内存 / 磁盘存在,执行器通过 tmp_table_param 管理其生命周期
  • 批量插入(INSERT …… VALUES (……), (……))执行器会合并为单次引擎层批量写入,减少日志刷盘次数
  • 如果 max_heap_table_size 太小,执行器在构建内部临时表时会自动落盘到ibtmp1,性能陡降

为什么 有些 SQL 在 prepare 阶段就失败

如果你用 PREPARE stmt FROM '……',MySQL 会在 prepare 阶段完成解析和部分语义检查(比如表是否存在、列名是否拼错),但 ** 不进行 权限验证 和执行计划生成 **。这意味着:PREPARE成功不代表 EXECUTE 一定成功。

典型错误:ERROR 1146 (42S02): Table 'db.nonexist' doesn't existPREPARE 时就报出;而 ERROR 1054 (42S22): Unknown column'xxx'in'field list' 也可能在此阶段被捕获——只要列名属于已知表结构。

  • 视图定义中的列名错误,会在 PREPARE 时暴露,因为视图元数据已加载
  • 存储过程内动态 SQL 的 PREPARE,若引用了过程参数但拼写错误(如CONCAT('SELECT * FROM t WHERE id =', v_id)v_id未声明),prepare 直接失败
  • EXECUTE时才检查权限,所以 PREPARE 成功但 EXECUTEERROR 1142 (42000): SELECT command denied很常见

整个流程里最容易被忽略的是:解析、优化、执行三个阶段共享同一套内存上下文(THD),但各自持有不同生命周期的对象。比如解析树在优化后可能被释放,而执行器依赖的 JOIN 结构体是全新分配的——调试时看错内存地址很容易误判问题阶段。

星耀云
版权声明:本站原创文章,由 星耀云 2026-01-08发表,共计1915字。
转载说明:转载本网站任何内容,请按照转载方式正确书写本站原文地址。本站提供的一切软件、教程和内容信息仅限用于学习和研究目的;不得将上述内容用于商业或者非法用途,否则,一切后果请用户自负。本站信息来自网络,版权争议与本站无关。