MySQL 系列 基础架构

尽可能全面的覆盖 MySQL 涉及的内容

Posted by lichao modified on February 24, 2021

基本架构示意图

MySQL 可以分为 Server 层和存储引擎层两部分。

Server 层

Server 层包括连接器、查询缓存、分析器、优化器、执行器等,涵盖 MySQL 的大多数核心服务功能,以及所有跨存储引擎的功能都在这一层实现,比如存储过程、触发器、视图、函数(内置函数如日期、时间、数学、加密函数)等,还有一个通用的日志模块 binlog 日志模块。

  • 连接器:身份认证和权限相关(登录 MySQL、程序建立连接)。
  • 查询缓存:执行查询语句的时候,会先查询缓存(这个功能不太实用,8版本也删掉了)。
  • 分析器:检查 SQL 语句语法是否正确;也会做一些校验,如当前数据库是否存在表、属性。
  • 优化器:按照 MySQL 认为最优的方案去执行。包括连接 join 顺序、索引使用。
  • 执行器:执行语句,然后从存储引擎返回数据。

查询缓存

MySQL拿到一个查询请求后,会先到查询缓存看看,之前是不是执行过这条语句。之前执行过的语句及其结果可能会以key-value对的形式,被直接缓存在内存中。key是查询的语句,value是查询的结果。如果查询能够直接在这个缓存中找到key,那么这个value就会被直接返回给客户端。

如果语句不在查询缓存中,就会继续后面的执行阶段。执行完成后,执行结果会被存入查询缓存中。可以看到,如果查询命中缓存,MySQL不需要执行后面的复杂操作,就可以直接返回结果,这个效率会很高。


存在的问题:

查询缓存的失效非常频繁,只要有对一个表的更新,这个表上所有的查询缓存都会被清空。因此很可能费劲地把结果存起来,还没使用就被一个更新全清空了。对于更新频繁的数据库来说,查询缓存的命中率会非常低。除非业务就是有一张静态表,很长时间才会更新一次。比如,一个系统配置表,那这张表上的查询才适合使用查询缓存。

MySQL提供了“按需使用”的方式。可以将参数query_cache_type设置成DEMAND,这样对于默认的 SQL 语句都不使用查询缓存。而对于确定要使用查询缓存的语句,可以用 SQL_CACHE显式指定,像下面这个语句一样:

1
mysql> select SQL_CACHE * from T where ID=10;

需要注意的是,MySQL 8.0版本直接将查询缓存的整块功能删掉了,也就是说8.0开始彻底没有这个功能了。

分析器

分析器先会做“词法分析”。输入的是由多个字符串和空格组成的一条SQL语句,MySQL需要识别出里面的字符串分别是什么,代表什么。

根据词法分析的结果,语法分析器会根据语法规则,判断输入的这个SQL语句是否满足MySQL语法。

优化器

优化器是在表里面有多个索引的时候,决定使用哪个索引;或者在一个语句有多表关联(join)的时候,决定各个表的连接顺序。比如执行下面这样的语句,这个语句是执行两个表的join:

1
mysql> select * from t1 join t2 using(ID)  where t1.c=10 and t2.d=20;
  • 既可以先从表t1里面取出c=10的记录的ID值,再根据ID值关联到表t2,再判断t2里面d的值是否等于20。
  • 也可以先从表t2里面取出d=20的记录的ID值,再根据ID值关联到t1,再判断t1里面c的值是否等于10。

这两种执行方法的逻辑结果是一样的,但是执行的效率会有不同,而优化器的作用就是决定选择使用哪一个方案。

索引选择优化

优化器选择索引的目的,是找到一个最优的执行方案,并用最小的代价去执行语句。在数据库里面,扫描行数是影响执行代价的因素之一。扫描的行数越少,意味着访问磁盘数据的次数越少,消耗的CPU资源越少。除了扫描行数,优化器还会结合是否使用临时表、是否排序、是否回表等因素进行综合判断。

扫描行数基于基数进行判断,即索引上不同值的个数,代表索引的区分度;通过采样统计的方式获取,InnoDB默认会选择N个数据页,统计这些页面上的不同值,得到一个平均值,然后乘以这个索引的页面数,就得到了这个索引的基数。当变更的数据行数超过1/M的时候,会自动触发重新做一次索引统计。

执行器

开始执行的时候,要先判断一下对这个表T有没有执行查询的权限,如果没有,就会返回没有权限的错误。

1
mysql> select * from T where ID=10;

针对上面的查询语句,执行器就会根据表的引擎定义,去使用这个引擎提供的接口:

  1. 调用 InnoDB 引擎接口取这个表的第一行,如果不符则跳过,如果符合则将这行存在结果集中;
  2. 调用引擎接口取“下一行”,重复相同的判断逻辑,直到取到这个表的最后一行。
  3. 执行器将上述遍历过程中所有满足条件的行组成的记录集作为结果集返回给客户端。

至此,这个查询语句就执行完成了。

在数据库的慢查询日志中看到一个rows_examined的字段,表示这个语句执行过程中扫描了多少行。这个值就是在执行器每次调用引擎获取数据行的时候累加的。在有些场景下,执行器调用一次,在引擎内部则扫描了多行,因此引擎扫描行数跟rows_examined并不是完全相同的。

存储引擎层

负责数据的存储和读取,采用可以替换的插件式架构,支持InnoDB、NDB、MyISAM、Memory等多个存储引擎。现在最常用的存储引擎是 InnoDB,它从 MySQL 5.5.5 版本开始就被当做默认存储引擎了,带有 redo log、undo log 日志模块支持事务。