MySQL架构组件的示例分析

这篇文章将为大家详细讲解有关Mysql架构组件的示例分析，小编觉得挺实用的，因此分享给大家做个参考，希望大家阅读完这篇文章后可以有所收获。

总体架构

一. 连接器

  连接器主要负责跟客户端建立连接、权限验证和管理连接，可以使用命令show processlist查看连接信息。当一个用户连接创建成功之后，权限信息就已经读入内存，之后再修改该用户的权限，如果不刷新的话，则无法生效。

  对于一个连接，如果长时间没有收到指令（处于空闲状态），那么达到一定的时间之后，连接器会断开这个链接。这个时间由参数wait_timeout控制，默认为8小时。

  连接器中的连接分为长连接和短连接：

• 长连接：连接成功后，客户端请求使用同一个连接

• 短连接：每次执行完请求后会断开连接，再有请求会重新建立连接

  由于在平时我们一般为了避免频繁反复创建连接的开销，都是使用的长连接，也就是长期维持一个连接不断开。但是要注意，一个连接管理了其在使用过程中占用的一些内存，会在连接断开的时候随连接一起释放。如果连接不断开，长期不处理一直堆积，则可能导致内存占用过大，被系统强杀。一般有两个解决方案：

• 定期断开长连接，每隔一段时间或执行一个占用大量内存的查询之后断开连接，从而释放内存，当需要查询的时候再重新创建连接

• 5.7之后的版本可以使用mysql_reset_connection来重新初始化连接资源，不需要重新连接和权限验证，而将连接恢复到新建时的状态。同时也会有一些其它影响，比如释放表锁、清除临时表、重置会话中设置的变量等等

二、 查询缓存

注：查询缓存8.0 版本后被废除

  连接创建成功之后就可以执行sql语句了，不过如果开启了查询缓存，那么在真正分析SQL之前会先从缓存中查询，如果缓存命中则直接返回。查询缓存就是一个Key-Value结构，Key是SQL语句，Value是对应的查询结果。如果缓存未命中，就会继续后面的查询操作。查询完成之后，会把结果存入查询缓存中。

  为什么查询缓存会被删除呢？因为查询缓存通常弊大于利。如果对一个表进行更新，那么这个表对应的查询缓存都会被清空，对于经常更新的表，查询缓存的失效会非常频繁，基本就不起作用，而且还有更新缓存的开销。对于那种基本会保持不变的数据表，倒是可以选择使用查询缓存，比如系统配置表等，这种表的缓存命中率会高些，可能能做到利大于弊，不过对于这种配置，我们还可以使用外部缓存。

  通过参数query_cache_type可以配置查询缓存，该参数有3个可选值，分别为：

• 0：关闭查询缓存

• 1：开启查询缓存

• 2：当SQL中有SQL_CACHE关键词时使用查询缓存，比如select SQL_CACHE * from t where xxx;

三、分析器

  如果查询缓存没有命中，那么SQL就需要真正得到执行，在执行之前需要对SQL进行解析，这个解析主要分为词法分析和语法分析两个步骤。

• 词法分析：从SQL中提取关键词，比如select 、from、表名、字段名等等

• 语法分析：根据词法分析的结果和MySQL定义的一些语法规则检查SQL语法是否合法，最终会生成一颗抽象语法树（AST）

四、 优化器

  优化器以分析器生成的AST为输入，对SQL进行优化，生成优化器认为的最优执行方案，交给执行器执行。优化过程包括SQL的逻辑转换和代价计算。

  逻辑转化就类似于Java的静态编译期优化，会对SQL进行一些"简化"，保证SQL转换前后执行结果一致。比如，where 1=1 and a.id = 2，可以相当于where a.id = 2。

  代价计算的主要目的是选择SQL执行的方式，包括是否使用索引、使用哪个索引、多表连接使用什么顺序等。代价分为服务层代价和引擎层代价，服务层代价主要是CPU相关，引擎层代价则主要是磁盘I/O相关。MySQL 5.7 引入了两个系统表mysql.server_cost和mysql.engine_cost来配置这两种代价，表中配置的就是各种操作对应的代价，比如临时表创建、排序、页读取等等。

  优化器会根据生成的查询计划和上述两种代价配置来计算一个查询计划的最终代价，在多个查询计划中选择代价最小的那一个交给执行器执行。但是要注意，代价最小，有时候并不一定代表执行时间就最短。

五、 执行器

  执行器会根据优化器选择的查询计划去执行SQL，执行之前还会校验请求用户是否拥有对应的查询权限，最终调用MySQL引擎层提供的接口，执行SQL语句并且返回结果。如果开启了查询缓存，结果还会存储在查询缓存中。

关于“MySQL架构组件的示例分析”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，使各位可以学到更多知识，如果觉得文章不错，请把它分享出去让更多的人看到。