MySQL逻辑架构 - SQL语句的执行都经历了哪些步骤

白菜1031

MySQL逻辑架构 - SQL语句的执行都经历了哪些步骤

从 MySQL 架构来理解,我们可以把 MySQL 拆解成几个零件,如下图所示

MySQL 逻辑架构模型

大体来说,MySQL 可以分为 Server层存储引擎层两部分。

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

存储引擎层负责数据的存储和提取。包括 MySQL 常见的存储引擎,包括 MyISAM、InnoDB 和 Memory 等,最常用的是 InnoDB,也是现在 MySQL 的默认存储引擎。
存储引擎也可以在创建表的时候手动指定,使用如下语句:

CREATE TABLE t (i INT) ENGINE = <Storage Engine>;

不同存储引擎的表数据存取方式不同,支持的功能也不同。
从图中可以看出,不同的存储引擎共用一个Server层,也就是从连接器到执行器的部分。

连接器

首先需要在 MySQL 客户端登陆才能使用,所以需要一个连接器来连接用户和 MySQL 数据库,我们一般是使用

mysql -h<host> -P<port> -u<用户名> -p[<密码>]

来进行 MySQL 登陆,和服务端建立连接。

虽然密码可以直接跟在 -p 后面写在命令行中,但这样可能会导致你的密码泄露。强烈建议不输入密码,直接运行命令,然后再再交互对话框中输入密码。

在完成 TCP 握手 后,连接器会根据你输入的用户名和密码验证你的登录身份。如果用户名或者密码错误,MySQL 就会提示 Access denied for user,然后客户端程序结束执行。如果用户名密码认证通过,连接器会到权限表里面查出你拥有的权限。之后,这个连接里面的权限判断逻辑,都将依赖于此时读到的权限。

这就意味着,一个用户成功建立连接后,即使你用管理员账号对这个用户的权限做了修改,也不会影响已经存在连接的权限。修改完成后,只有再新建的连接才会使用新的权限设置。

连接完成后,如果没有后续的动作,这个连接就处于空闲状态,可以使用 show processlist 命令中看到它。

mysql> show processlist;
+--------+-------------+---------------------+--------+---------+------+----------+------------------+
| Id     | User        | Host                | db     | Command | Time | State    | Info             |
+--------+-------------+---------------------+--------+---------+------+----------+------------------+
| 214416 | master      | 124.126.130.4:29734 | db_name | Sleep   |   13 |          | NULL             |
| 214417 | master      | 124.126.130.4:29754 | db_name | Query   |    0 | starting | show processlist |
+--------+-------------+---------------------+--------+---------+------+----------+------------------+
2 rows in set (0.07 sec)

其中的Command列显示为 Sleep 的这一行,就表示现在系统里面有一个空闲连接。客户端如果太长时间没动静,连接器就会自动将它断开。这个时间是由参数 wait_timeout 控制的,默认值是8小时。

如果在连接被断开之后,客户端再次发送请求的话,就会收到一个错误提醒: Lost connection to MySQL server during query。这时候如果你要继续,就需要重连,然后再执行请求了。

数据库里面,长连接是指连接成功后,如果客户端持续有请求,则一直使用同一个连接。短连接则是指每次执行完很少的几次查询就断开连接,下次查询再重新建立一个。

建立连接的过程通常是比较复杂的,所以建议在使用中要尽量减少建立连接的动作,也就是尽量使用长连接。

但是全部使用长连接后,你可能会发现,有些时候MySQL占用内存涨得特别快,这是因为MySQL在执行过程中临时使用的内存是管理在连接对象里面的。这些资源会在连接断开的时候才释放。所以如果长连接累积下来,可能导致内存占用太大,被系统强行杀掉(OOM),从现象看就是MySQL异常重启了。

怎么解决这个问题呢?你可以考虑以下两种方案。

  1. 定期断开长连接。使用一段时间,或者程序里面判断执行过一个占用内存的大查询后,断开连接,之后要查询再重连。
  2. 如果你用的是 MySQL 5.7 以上的版本,可以在每次执行一个比较大的操作后,通过执行 mysql_reset_connection 来重新初始化连接资源。这个过程不需要重连和重新做权限验证,但是会将连接恢复到刚刚创建完时的状态。

查询缓存

连接完成后,你就可以执行 SQL 语句了,这行逻辑就会来到第二步:查询缓存

MySQL 在得到一个执行请求后,会首先去 查询缓存 中查找,是否执行过这条 SQL 语句,之前执行过的语句以及结果会以 key-value 对的形式,被直接放在内存中。key 是查询语句,value 是查询的结果。如果通过 key 能够查找到这条 SQL 语句,就直接返回 SQL 的执行结果。

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

MySQL 查询缓存流程图

但是大多数情况下,不建议使用查询缓存
因为查询缓存的失效非常频繁,只要在 MySQL 中对某一张表执行了更新操作,那么这张表上的所有的查询缓存就会失效,对于更新频繁的数据表来说,查询缓存的命中率会非常低。除非你的业务就是有一张静态表,很长时间才会更新一次。比如,一个系统配置表,那这张表上的查询才适合使用查询缓存。

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

select SQL_CACHE * from T where ID=10;

需要注意的是,MySQL 8.0版本直接将查询缓存的整块功能删掉了。

分析器

如果没有命中查询缓存,就要开始真正执行 SQL 语句了。
首先,MySQL 会根据你写的 SQL 语句进行解析,分析器会先做 词法分析,你输入的是由多个字符串和空格组成的一条 SQL 语句,MySQL 需要识别出里面的字符串是什么,代表什么。

然后进行 语法分析,根据词法分析的结果, 语法分析器会根据语法规则,判断你输入的这个 SQL 语句是否满足 MySQL 语法。如果 SQL 语句不正确,就会提示 You have an error in your SQL syntax

优化器

经过分析器的词法分析和语法分析后,这条 SQL 就合法了,MySQL 就知道你要做什么了。但是在执行前,还需要经过优化器的处理。

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

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。

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

优化器会判断你使用了哪种索引,使用了何种连接,确定效率最高的执行方案。

执行器

MySQL 通过分析器知道了你的 SQL 语句是否合法,你想要做什么操作,通过优化器知道了该怎么做效率最高,然后就进入了执行阶段,开始执行这条 SQL 语句。

开始执行的时候,MySQL 首先会判断你对要操作的表有没有执行这条语句的权限。

  • 如果没有权限,就会返回没有权限的错误(ERROR 1142 (42000): SELECT command denied to user 'foo'@'localhost' for table 'bar')。
  • 如果有权限,就打开表继续执行。

打开表的时候,执行器就会根据表的引擎定义,去使用这个引擎提供的接口查询数据返回给客户端。

至此,MySQL 对于一条语句的执行过程也就完成了。

参考《MySQL实战45讲》丁奇
阅读 1.2k

全栈札记
欢迎关注同名公众号。全栈工程师成长札记。 主要记录MySQL、Redis、ElasticSearch、MongoDB、Linux、She...
5.3k 声望
1.6k 粉丝
0 条评论
你知道吗?

5.3k 声望
1.6k 粉丝
文章目录
宣传栏