MySQL 简单查询语句执行过程分析（一）词法分析 & 语法分析 - 哈喽比特

504次阅读 | 发布于2年以前

简单查询语句执行过程分析，是 MySQL 执行过程分析系列文章的基础，会对查询语句执行过程中各个阶段进行比较详细的分析。原本是计划写成一篇文章的，但是这样一来文章的内容就会很长，不利于阅读，经过一番考虑之后，计划把 MySQL 简单查询语句执行过程分析按执行阶段拆分为 6 篇文章，本文是第 1 篇。

以前在学校学习编译原理的时候，记得书上是把词法分析和语法分析作为两个阶段分开讲解的，工作这些年没有再去深入的学习过编译原理相关的东西，所以我的记忆一直停留在：词法分析和语法分析是两个独立的阶段。但是，在 MySQL 的执行过程中，词法分析和语法分析是融合在一起的，是一个你中有我，我中有你的过程。

词法分析 & 语法分析阶段的入口是语法分析器，语法分析器调用词法分析器读取一个 token 进行分析，分析完后再读取一个 token，直到分析完所有的 token，结束整个过程。所以，词法分析 & 语法分析阶段实际上是由语法分析器驱动的，语法分析器是大哥，词法分析器是小弟。

MySQL 的词法分析程序是自己实现的，没有使用开源的 Lex / Flex 工具来生成词法分析器。语法分析则使用了开源工具 Bison。

Yacc 也是一种语法分析器生成工具，一般和 Lex 配套使用。Bison 相比于 Yacc 支持更复杂的语法形式，一般和 Flex 配套使用。

MySQL 之所以没有使用和 Bison 配套的 Flex 来生成词法分析器，我猜测主要原因是，Flex 词法分析器是通用工具，为了支持各种语言的通用场景，生成的词法分析器代码会比较复杂，代码复杂就意味着执行效率的下降，对于像 MySQL 这样单机要尽可能支持更高并发的服务端程序来说，这是不能忍受的，所以不如用最简单的逻辑，最少的代码来实现自己的词法分析程序。

MySQL 虽然支持主从集群，从库理论上来说是可以无限扩展的，但是主库却不行，所以要尽量在可能之处提升性能，哪怕是一点点呢？一个连接提升一点点，并发上来之后，所提升的性能也还是比较可观的。

为什么语法分析使用了 Bison 呢？

语法分析逻辑相对于词法分析来说比较简单，主要就是使用 LALR 算法，根据语法规则的描述，对词法分析阶段解析出来的 token 不断的使用移进 / 归约操作直到找到一条完整的 SQL 语句，然后进行初始化操作。

移进 可以理解为把解析出来的 token 一个一个的入栈，归约 可以理解为把多个 token 出栈，组合成更上一级的语法单元并入栈，循环往复，直到把所有 token 归约到根结点，就结束了一条 SQL 的解析过程，然后就可以对该 SQL 进行初始化操作了。当然，实际的移进 / 归约过程会比这个复杂一些，这里打了个比方，只是为了让大家有一点印象。

关于词法分析和语法分析就说这么多了，有兴趣的朋友可以去看看《flex 与 bison 中文版》这本书。

本文讲解的查询语句执行过程是以 t_recbuf 表及其查询语句为基础的，示例 SQL 中涉及不到的流程，本文不会介绍，以保证逻辑简单，表结构和示例 SQL 如下：

-- 表结构
CREATE TABLE `t_recbuf` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `i1` int(10) unsigned DEFAULT '0',
  `str1` varchar(32) DEFAULT '',
  `str2` varchar(255) DEFAULT '',
  `c1` char(11) DEFAULT '',
  `e1` enum('北京','上海','广州','深圳','天津','杭州','成都','重庆','苏州','南京','洽尔滨','沈阳','长春','厦门','福州','南昌','泉州','德清','长沙','武汉') DEFAULT '北京',
  `s1` set('吃','喝','玩','乐','衣','食','住','行','前后','左右','上下','里外','远近','长短','黑白','水星','金星','地球','火星','木星','土星','天王星','海王星','冥王星') DEFAULT '',
  `bit1` bit(8) DEFAULT b'0',
  `bit2` bit(17) DEFAULT b'0',
  `blob1` blob,
  `d1` decimal(10,2) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=2001 DEFAULT CHARSET=utf8;

-- 查询语句
select * from t_recbuf where i1 > 49276

接下来我们进入正题，讲讲在词法分析 & 语法分析过程中，MySQL 主要干了哪些事情？

1 . 初始化字段

对于 select 子句中的每个字段，都会创建一个 Item_field 类（或子类）的实例。

后面的内容中，Item_field 类以及其子类的实例都会直接说成 Item_field 类实例。

select子句中，字段可能有 2 种类型，一种是星号（*），一种是普通字段，星号会用 Item_asterisk 类实例化，而 Item_asterisk 类是 Item_field 类的子类。普通字段就直接用 Item_field 类实例化。

词法分析 & 语法分析阶段，各字段只是完成了 Item_field 类的实例化，但是还没有对应到表中真实的字段。此时，Item_field 类实例就像刚刚成形的小蝌蚪，还没有找到妈妈。它的妈妈是 Field 类（或子类）的实例。要等到查询准备阶段，Item_field 类实例才会去找妈妈，找到妈妈之后，Item_field 类实例中的 field 属性会指向找到的 Field 类（或子类）实例，从此以后，小蝌蚪和妈妈就过上了幸福快乐的生活。

关于 Item_field 类实例怎么找到对应的 Field 类（或子类）实例，到查询阶段我们会详细讲，在这里先有个印象就好了。

2 . 初始化表

对于 from 子句中的每个表，都会创建一个 TABLE_LIST 类的实例，TABLE_LIST 类实例中只保存了数据库名、表名、表别名、索引提示这几个我们使用过程中有感知的属性，TABLE_LIST 类实例中有个很重要的属性 table，它的类型是 TABLE，这个类的实例才是真正保存着表中所有信息的地方。等到查询准备阶段，才会找到 TABLE_LIST 类实例对应的 TABLE 类实例。

相信大家能够看到 TABLE_LIST 和 TABLE 又是一个小蝌蚪找妈妈的故事。

这里要特别说明的一点是数据库名，我们一般在写 select 语句的时候，from 子句中的表名前面是不会带上数据库名的，就像本文示例 SQL 中的一样。在词法分析 & 语句分析阶段，初始化表的时候，如果表名前面没有带上数据库名，就会把当前连接中保存的数据库名读取出来，保存到 TABLE_LIST 类实例的属性中，如果表名前面带了数据库名，则把自带的数据库名保存到 TABLE_LIST 类实例的属性中。

前面提到的索引提示信息指的是像下面 2 条 SQL 中的 force index 以及 ignore index。

select * from t2 force index(idx_i1) where i1 = 'xyz';

select * from t2 ignore index(idx_i1) where i1 = 'xyz'

3 . 初始化 where 条件

初始化 where 条件要比初始化字段复杂，本文示例 SQL 中的 where 条件只有一个条件（i1 > 49276）。

大于号(>)属于双目运算符，涉及 2 个操作数和 1 个比较运算符，所以 where 条件中，会创建 3 个实例：

左操作数：i1 字段，是一个普通的字段，创建一个 Item_feild 类的实例，此实例同样没有关联真正的 Field 类（或子类）实例
右操作数：49276 是一个常数，创建一个 Item_int 类的实例。
比较运算符：大于号(>) 在 MySQL 中实现为一个类，会创建一个 Item_func_gt 类的实例，该类的实例中保存着它的两个操作数，属性 a 为左操作数，属性 b 为右操作数，简单粗暴。

Item_func_gt 类实例有一个比较重要的属性 func，是个函数指针，它是用来执行 i1 字段和 49276 之间的比较的，但是，此时，MySQL 并不知道 i1 字段是什么类型，不知道该怎么比较它们两个谁大谁小，所以 func 属性的值到现在还是个 NULL，要等到查询准备阶段才会被赋值。又是要等查询准备阶段，可见，查询准备阶段的任务是比较繁重的。

以上就是本文的全部内容了，整个过程是比较简单的，没有太多的逻辑，基本就是搞了个框架出来，都要等到查询准备阶段去填充内容。

如果觉得有用，请帮忙转发本文让更多的朋友看到，谢谢 ^_^