01|基础架构:一条SQL查询语句是如何执行的

2019-05-22  本文已影响0人  GEFM

MySQL执行语句的基本架构示意图:

查询:select * from T where id =10

执行流程

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

所有跨引擎的功能都在Server层实现,比如存储过程,触发器,视图

存储引擎层的架构模式是插件式的,支持InnoDB,MyISAM,Memory等多个引擎。

我们最常用的存储引擎是InnoDB,默认的存储

连接器

使用数据库之前,需要连接数据库,完成TCP握手后,开始认证身份,判断用户名和密码是否一致,如果不正确的话,“Access denied for user” 错误,客户端连接失败,执行结束。如果用户名和密码都对,连接器会从权限表里面查出你拥有的权限。

连接完成后,如果没有后续的动作,这个连接就处于空闲状态,8个小时之内都是空闲的,连接器会自动断开。

长连接: 客户端持续发请求

短连接:只用到几次

建立连接过程麻烦,尽量减少建立连接的动作,建议使用长连接

但是长期使用长连接,MySQL占用的内存涨的特别快,这是因为MySQL在执行过程中临时使用的内存是管理在连接对象里面的,这些资源会在连接断开的时候才释放,所以如果长期累积下来,可能导致内存占用太大,被系统杀掉,MySQL会被自动重启。

怎么解决:

1.定期断开连接

2.使用的是Mysql5.7这个之后的版本,可以通过执行mysql_reset_connection来重新初始化连接资源。恢复到刚刚创建完时的状态。

查看缓存

建立连接成功之后,可以执行select语句了,执行逻辑来到第二步:查看缓存

MySQL拿到一个查询请求之后,会先到查询缓存区看看之前有没有执行过这条语句,有的话,直接获取结果,这个效率高。缓存区以key—value形式:key值是查询的语句,value值是查询的结果。如果之前没有查询过,再执行后续的步骤。可以手动设置是否要每次查询缓存区。

但是如果只要对一个表进行了更新之后,关于个表的所有缓存都会被清空掉。MySQL8.0之后缓存机制被删掉了。

分析器

如果缓存区没有查到结果,这时候真正要开始执行查询与语句了。

分析器首先做“词法分析”,MySQL识别“select”,这是一个查询语句,之后会把T识别成表名T,id识别成列id; 然后做“语法分析”,如果语句错误,例如单词有误,会报错。

优化器

经过了分析器之后,MySQL就知道你要做什么了,在开始执行之前,还要经过优化器的处理。

优化器会分析多种情况,判断哪种方式查询的效率更高。优化器的作用就是决定选择使用哪一种方案。

执行器

MySQL就知道你要做什么了,通过优化器知道该采取哪个方案了,接下来就是执行器的阶段了,开始执行语句了。

开始执行的时候,要先判断一下你对这个表T有没有执行查询的权限,如果没有,就会返回没有权限的错误。在工程实现上,如果命中查询缓存,会在查询缓存返回结果的时候,做权限验证。查询也会在优化器之前调用precheck验证权限。

如果有权限,就打开表继续执行。打开表的时候,执行器就会根据表的引擎定义,去使用这个引擎提供的接口。

比如我们这个例子中的表T中, ID字段没有索引,那么执行器的执行流程是这样的:

1.调用InnoDB引擎接口取这个表的第一行,判断ID值是不是10 ,如果不是则跳过,如果是则将这行存在结果集中;

2.调用引擎接口取”下一行”, 重复相同的判断逻辑,直到取到这个表的最后一行。

3.执行器将上述遍历过程中所有满足条件的行组成的记录集作为结果集返回给客户端。

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

对于有索引的表,执行的逻辑也差不多。第一次调用的是“取满足条件的第一行”这个接口,之后循环取“满足条件的下一行” 这个接口,这些接口都是引擎中已经定义好的。

你会在数据库的慢查询日志中看到一个rows_ examined的字段,表示这个语句执行过程中扫描了多少行。这个值就是在执行器每次调用引擎获取数据行的时候累加的。

在有些场景下,执行器调用一次,在引擎擎内部则扫描了多行,因此引擎扫描行数跟rows_ examined并不是完全相同的。

执行循序
上一篇下一篇

猜你喜欢

热点阅读