MySQL 简单查询语句执行过程分析(一)词法分析 & 语法分析

发布于 2022-4-24 19:51
浏览
0收藏

作者 | 操盛春
来源 | 一树一溪(ID:lovespring52)
转载请联系授权(微信ID:csch52)

简单查询语句执行过程分析,是 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,要等到查询准备阶段才会被赋值。又是要等查询准备阶段,可见,查询准备阶段的任务是比较繁重的。

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

收藏
回复
举报
回复
添加资源
添加资源将有机会获得更多曝光,你也可以直接关联已上传资源 去关联
    相关推荐