在讲SQL语句是如何执行之前,我想先带你简单认识下MySQL的基本架构。
借用一张别人的图
大体来说,MySQL 可以分为 Server 层和存储引擎层两部分。从图中我们可以看到多个存储引擎共有一个Server层。
Server 层包括连接器、查询缓存、分析器、优化器、执行器等,涵盖 MySQL 的大多数核心服务功能,以及所有的内置函数(如日期、时间、数学和加密函数等),所有跨存储引擎的功能都在这一层实现,比如存储过程、触发器、视图等。
什么叫跨存储引擎层?可以简单理解为多张表,因为每张表都可以指定存储引擎
连接器负责跟客户端建立连接、获取权限、维持和管理连接。连接命令一般是这么写的:
mysql -h$ip -P$port -u$user -p
注意:一个用户成功建立连接后,即使你用管理员账号对这个用户的权限做了修改,也不会影响已经存在连接的权限。修改完成后,只有再新建的连接才会使用新的权限设置。
MySQL 8.0 已移除
连接建立完成后,如果你执行的是查询语句,执行逻辑就会来到第二步:查询缓存。
MySQL 拿到一个查询请求后,会先到查询缓存看看,之前是不是执行过这条语句。之前执行过的语句及其结果可能会以 key-value 对的形式,被直接缓存在内存中。key 是查询的语句,value 是查询的结果。如果你的查询能够直接在这个缓存中找到 key,那么这个 value 就会被直接返回给客户端。如果语句不在查询缓存中,就会继续后面的执行阶段。
但是由于查询缓存的失效非常频繁,只要有对一个表的更新,这个表上所有的查询缓存都会被清空。所以不建议使用。这里也不展开讲了。
如果没有命中查询缓存,就要开始真正执行语句了。首先,MySQL 需要知道你要做什么,因此需要对 SQL 语句做解析。
分析器主要有词法分析和语法分析。一般语法报错都是在这个阶段返回。
经过了分析器,MySQL 就知道你要做什么了。在开始执行之前,还要先经过优化器的处理。也就是优化器决定怎么做。
优化器是在表里面有多个索引的时候,决定使用哪个索引;或者在一个语句有多表关联(join)的时候,决定各个表的连接顺序。
比如你执行下面这样的语句,这个语句是执行两个表的 join:
mysql> select * from t1 join t2 using(ID) where t1.c=10 and t2.d=20;
这两种执行方法的逻辑结果是一样的,但是执行的效率会有不同,而优化器的作用就是决定选择使用哪一个方案。
MySQL 通过分析器知道了你要做什么,通过优化器知道了该怎么做,于是就进入了执行器阶段,开始执行语句。
请注意,这里会再次判断是否有相关表的权限:比如如果有个触发器,得在执行器阶段(过程中)才能确定。如果走的是查询缓存,也会在查询缓存之前校验相关权限
权限校验通过后,那么执行器就需要去调用相关表的存储引擎的读写接口来获取结果并返回。
例如对于如下语句
mysql> select * from T where ID=10;
假设表 T 中 ID 字段没有索引,那么执行器的执行流程是这样的:
至此,这个语句就执行完成了。
存储引擎层负责数据的存储和提取。我们可以为每张表指定不同的存储引擎。其架构模式是插件式的,支持 InnoDB、MyISAM、Memory 等多个存储引擎。现在最常用的存储引擎是 InnoDB,它从 MySQL 5.5.5 版本开始成为了默认存储引擎。
InnoDB
大家都很熟悉,和其他存储引擎的区别这里不再展开。我们学习MySQL事务中常提到的 redo log
和 undo log
就是 InnoDB
独有的,这两者都在存储引擎层。
Binlog在Server层
这个只提两点吧
Memory引擎亦如其名,内存表。内存表把数据放在内存中,会带来两个显著的影响:
这里不细说,仅仅提一下。
再次回到开始那张图,我们就可以知道一条SQL是如何执行的了。
这篇文章说的很简单,仅仅写了一个SQL大概的执行流程,而对于索引的选择,缓存,log等都没有提到。本篇只是要带你认识下存储引擎外的操作,在下一篇文章中,我会带你仔细分析下一条SQL更新语句是如何执行的,InnoDB 内部是如何设计的。
原文:https://www.cnblogs.com/lifan1998/p/14927849.html