MySQL 简单查询语句执行过程分析（二）查询准备阶段

发表于 2年以前 | 总阅读数：539 次

本文是 MySQL 简单查询语句执行过程分析 6 篇中的第 2 篇，第 1 篇请看这里： [MySQL 简单查询语句执行过程分析（一）词法分析 & 语法分析]

这一篇主要讲的内容是一条简单查询语句，在查询准备阶段会干哪些事情？分 3 个部分：

打开表
select * 替换为表字段
填充 where 条件

示例表及 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

接下来，我们进入正题，展开讲讲这 3 部分内容。

1 . 打开表

从存储引擎读取数据之前，MySQL 需要把 SQL 中涉及的所有表的信息读取出来。研究源码之前，我想象中的打开表就是读取 frm 文件中的信息，构造出来一个对象啥的，然后就没有然后了，不知道正在看文章的你想象中的打开表的过程是什么样的呢？

MySQL 打开表的过程比较复杂，读取 frm 文件并进行处理的一个方法就有 1700+ 行代码，还不包括调用的其它方法。

正是因为打开表的过程复杂，而代码复杂意味着执行效率下降，这对于 MySQL 来说是不能接受的，所以必定要有优化手段。

每次执行 SQL 的时候，不管是增、删、改、查，还是修改表结构，都要打开表，可见打开表是个非常频繁的操作，对于这种复杂而又频繁的操作，能用什么优化手段呢？聪明如你，一定能够想到，当然是用缓存了。

没错，MySQL 中就是用缓存的思想实现的，而且是本机内存缓存，效率极高。天下武功，唯快不破，为了快的极致，MySQL 还不只用了一级缓存，而是用了两级缓存。

一级缓存

一级缓存是TABLE 类实例缓存，顾名思义，该缓存中保存的就是已经创建好的 TABLE 类实例，是之前的连接中使用过的 TABLE 类实例，用完之后又放回到缓存中了，所以从这个缓存里拿到的 TABLE 类实例，可以直接使用。打开表时，第一步就是从这个缓存中去拿 TABLE 类实例。

TABLE 类实例中保存的是表结构信息。

从缓存中查找 TABLE 类实例，需要一个 key，这个 key 是由数据库名和表名组成的，key 的形式是 dbname_tablename。

TABLE 类实例缓存实际上并不是只有 1 个，而是有多个，数量由系统变量 table_open_cache_instances 控制，默认为 16。总共可以缓存多少个实例由系统变量 table_open_cache 控制，默认为 2000，所以默认情况下，每个 TABLE 类实例缓存可以缓存 2000 / 16 = 125 个 TABLE 类实例。

同一个表的 TABLE 类实例，在缓存中可以存在很多个，理论上限是 table_open_cache，就是缓存的全都是同一个表的 TABLE 类实例。

那么，怎么确定要从哪个 TABLE 类实例缓存读取 TABLE 类实例呢？是这样的：每个连接都会有一个线程 ID，用线程 ID % table_open_cache_instances 得到一个序号，通过序号找到对应的 TABLE 类实例缓存。

既然是缓存，就会涉及到缓存满了怎么办的问题，对于 TABLE 类实例缓存，当往缓存中放入 TABLE 类实例时，会判断缓存是否已满，如果满了，则按照最近最少使用原则，把多出来的 TABLE 类实例释放掉。还有另一种方式就是手动了，执行 FLUSH TABLES 命令可以清空缓存。

如果从一级缓存中没有读取到 TABLE 类实例，就要进入二级缓存的处理流程了，二级缓存逻辑比一级缓存复杂，所以执行效率要低一些。

二级缓存

二级缓存是 TABLE_SHARE 类实例缓存，可以缓存的 TABLE_SHARE 类实例数量由系统变量 table_definition_cache 控制，默认为 1400，每个表只对应一个 TABLE_SHARE 实例，从这个缓存中读取到 TABLE_SHARE 类实例以后，用该实例中的各个属性去创建并初始化一个 TABLE 类实例，然后就可以使用 TABLE 类实例进行后续的操作了。

TABLE_SHARE 类实例中保存的也是表结构信息，TABLE 类实例中的数据就是从 TABLE_SHARE 类实例中复制过来的。

如果从二级缓存中没有读取到可以用于初始化 TABLE 类实例的表结构信息，就只能从表 frm 文件中读取了。

读取 frm 文件

到这一步，要从 frm 文件中读取表名、表注释、字段名、字段类型、字段注释、索引等所有信息，并且进行一大堆各种检查，然后创建 TABLE_SHARE 类实例，再用 TABLE_SHARE 类实例创建 TABLE 类实例。

从 frm 文件中读取信息构建 TABLE_SHARE 类实例这个过程，逻辑太复杂，执行效率就更低了。

然而不管怎样，只要表存在，并且服务器没问题，最多执行完上面 3 个步骤，就能拿到 TABLE 类实例了，然后就可以赋值给昨天说的 TABLE_LIST 的 table 属性了，从此，TABLE_LIST 就完整了。

2 . select * 替换为表字段

我们在写 select 语句的过程中，经常会用到星号（*），表示查询表中所有字段，但是表中并没有一个星号字段用来表示所有字段，所以在查询准备阶段，会把星号替换为表中的所有字段。

这个替换过程比较简单，直接遍历表中的所有字段，为每个字段创建一个 Item_field 类实例，并且由于是直接遍历表中的 Field 子类实例列表，在创建 Item_field 类实例的时候就关联上了 Field 子类实例，不需要进行小蝌蚪找妈妈的过程了。

遍历完表中所有字段之后，形成一个 Item_field 列表，替换掉星号（*）对应的 Item_field 列表就行了，至此，就完成了 select 语句中星号替换为表字段的过程了。

3 . 填充 where 条件

示例 SQL 的 where 中只有一个条件（i1 > 49276），条件中的 i1 字段也是一个 Item_field 类实例，需要找到对应表中的字段，并且关联上该字段的 Field 子类实例。

where 条件中的字段找到对应 Field 子类实例的过程，是这样的：遍历 SQL 中使用到的表，在遍历每个表的过程中，根据字段名查找表中有没有这个字段，如果没有，继续去下一个表找。如果找到了呢？那也不是就万事大吉了，像 i1 > 49276 中的 i1 字段，前面没有限定数据库名和表名，也还要继续遍历下一个表查找字段。