MySQL的逻辑架构
最后更新于
这有帮助吗?
最后更新于
这有帮助吗?
负责与客户端建立TCP连接,经过三次握手成功后, MySQL 服务器对 TCP 传输过来的账号密码做身份认证、权限获取。
TCP 连接收到请求后,必须要分配给一个线程专门与这个客户端的交互。所以还会有个连接池,去走后面的流程。每一个连接从线程池中获取线程,省去了创建和销毁线程的开销。
SQL Interface: SQL接口
接收用户的SQL命令,并且返回用户需要查询的结果。比如SELECT ... FROM就是调用SQL Interface MySQL支持DML(数据操作语言)、DDL(数据定义语言)、存储过程、视图、触发器、自定义函数等多种SQL语言接口
Parser: 解析器
对SQL语句进行语法分析、语义分析,解析为语法树。
如果解析过程出错,说明SQL语法是错误的。
验证客户端是否具有执行权限。
对SQl查询进行语法上的优化,进行查询重写。
Optimizer: 查询优化器
使用解析器返回的语法树生成一个执行计划。执行计划表明该SQL应该使用哪儿些索引、表之间的连接顺序如何。
然后使用生成的执行计划调用存储引擎提供的方法来真正的执行查询,并将结果返回给用户。
它使用选取-投影-连接
策略进行查询:
Caches & Buffers: 查询缓存组件
MySQL内部维持着一些Cache和Buffer,比如Query Cache用来缓存一条SELECT语句的执行结果,如果能够在其中找到对应的查询结果,那么就不必再进行查询解析、优化和执行的整个过程了,直接将结果反馈给客户端。这个缓存机制是由一系列小缓存组成的。比如表缓存,记录缓存,key缓存,权限缓存等 。这个查询缓存可以在 不同客户端之间共享 。
在MySQL8.0缓存已经被去除,因为缓存的命中条件太低。
插件式存储引擎层( Storage Engines),真正的负责了MySQL中数据的存储和提取,对物理服务器级别维护的底层数据执行操作,服务器通过API与存储引擎进行通信。不同的存储引擎具有的功能不同,这样我们可以根据自己的实际需要进行选取。
所有的数据,数据库、表的定义,表的每一行的内容,索引,都是存在 文件系统 上,以 文件 的方式存在的,并完成与存储引擎的交互。当然有些存储引擎比如InnoDB,也支持不使用文件系统直接管理裸设备,但现代文件系统的实现使得这样做没有必要了。在文件系统之下,可以使用本地磁盘,可以使用DAS、NAS、SAN等各种存储系统。
Server 如果在查询缓存中发现了这条 SQL 语句,就会直接将结果返回给客户端;如果没有,就进入到解析器阶段。
在MySQL8.0下,查询缓存已经被移除,主要是因为:
查询缓存是提前把查询结果缓存起来,这样下次不需要执行就可以直接拿到结果。
只有 相同的查询操作才会命中查询缓存,两个查询请求在任何字符上的不同(例如:空格、注释、大小写),都会导致缓存不会命中。因此 MySQL 的 查询缓存命中率不高。
如果查询请求中包含某些系统函数、用户自定义变量和函数、一些系统表,那这个请求就不会被缓存。比如函数NOW()
所得到的结果始终不同
MySQL的缓存系统会监测涉及到的每张表,只要该表的结构或者数据被修改,如对该表使用了 INSERT
、 UPDATE
、 DELETE
、 TRUNCATE TABLE
、 ALTER TABLE
、 DROP TABLE
或 DROP DATABASE
语句,那使用该表的所有高速缓存查询都将变为无效并从高速缓存中删除!对于 更新压力大的数据库 来说,查询缓存的命中率会非常低。
MySQL5.7下开启查询缓存:
在MySQL5.7下,查询缓存的功能是默认关闭的
查看查询缓存是否开启:
开启查询缓存,修改my.cnf
查询查询缓存的命中率:
Qcache_free_blocks表示已分配内存块中空闲块数量;
Qcache_total_blocks表示当前查询缓存占用的内存块数量;
Qcache_free_memory表示缓存空闲空间大小;
Qcache_hits表示缓存命次数;
Qcache_inserts表示缓存未命中时,数据写入缓存次数;
Qcache_queries_in_cache表示缓存查询语句数量;
Qcache_lowmem_prunes表示缓存修剪次数,缓存满时,会使用LRU算法移除最久未被使用缓存,此值较大,说明缓存空间太小;
Qcache_not_cached表示没有被缓存的查询sql数量。
解析器负责对SQL语句进行语法分析、语义分析。
主要分为以下几个步骤:
词法分析
MySQL 从你输入的select
这个关键字识别出来,这是一个查询语句。它也要把字符串T
识别成“表名 T
,把字符串ID
识别成列 ID
。
语法分析
根据词法分析的结果,语法分析器(比如:Bison)会根据语法规则,判断你输入的这个 SQL 语句是否 满足 MySQL 语法 。如果SQL语句正确,则会生成一个这样的语法树:
在优化器中会确定 SQL 语句的执行路径,比如是根据全表检索 ,还是根据索引检索等。查询优化又分为逻辑查询优化和物理查询优化两个阶段:
逻辑查询优化:通过改变SQL语句让SQL查询变得更高效,同时为屋里查询优化提供更多的候选执行计划。通常采用对SQL语句进行等价变换并对查询重写。比如,对等价谓词重写、对视图重写、对子查询优化、条件简化、嵌套连接消除等。
物理查询优化:也是对查询重写,他会通过物理计算,计算各种物理路径的代价,从中虚着呢最小的作为执行计划。在这个阶段中,对于单表与多表的连接操作,需要高效的使用索引,提升查询效率。
优化器最终将会生成一个执行计划。
执行器负责执行优化器提供的执行计划。这时候,MySQL才开始读取真实的数据表。
根据执行计划执行SQL,并调用底层存储引擎的API,真实去访问数据,获取结果,并返回给客户端
如果是8.0以下,且开启了查询缓存,将会把查询结果缓存到查询缓存中
确认profiling是否开启:
开启profiling:
第一次执行:
第二次查询: