MySQL 体系架构

本文主要是介绍MySQL 体系架构，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

MySQL学习系列

可以看出 MySQL 最上层是连接组件。下面服务器是由连接池、 管理工具和服务、 SQL 接口、 解析器、 优化器、 缓存、 存储引擎、 文件系统组成。

连接池： 由于每次建立建立需要消耗很多时间， 连接池的作用就是将这些连接缓存下来， 下次可以直接用已经建立好的连接， 提升服务器性能。

管理工具和服务： 系统管理和控制工具， 例如备份恢复、 Mysql 复制、 集群等

SQL 接口： 接受用户的 SQL 命令， 并且返回用户需要查询的结果。 比如 select
from 就是调用 SQL Interface

解析器: SQL 命令传递到解析器的时候会被解析器验证和解析。 解析器主要功能：

• a . 将 SQL 语句分解成数据结构， 并将这个结构传递到后续步骤， 以后 SQL
  语句的传递和处理就是基于这个结构的
• b. 如果在分解构成中遇到错误， 那么就说明这个 sql 语句是不合理的

优化器： 查询优化器， SQL 语句在查询之前会使用查询优化器对查询进行优化。

缓存器： 查询缓存， 如果查询缓存有命中的查询结果， 查询语句就可以直接去查询缓存中取数据。

这个缓存机制是由一系列小缓存组成的。 比如表缓存， 记录缓存， key 缓存，权限缓存等。

存储引擎、 文件系统的作用， 后面会细讲。

一、连接层

服务器处理客户端请求

当 MySQL 启动（MySQL 服务器就是一个进程） ， 等待客户端连接， 每一个客户端连接请求， 服务器都会新建一个线程处理（如果是线程池的话， 则是分配一个空的线程） ， 每个线程独立， 拥有各自的内存处理空间

show VARIABLES like '%max_connections%

mysql> show variables like '%max_connections%';
+------------------------+-------+
| Variable_name          | Value |
+------------------------+-------+
| max_connections        | 151   |
| mysqlx_max_connections | 100   |
+------------------------+-------+
2 rows in set (0.01 sec)

连接到服务器， 服务器需要对其进行验证， 也就是用户名、 IP、 密码验证，一旦连接成功， 还要验证是否具有执行某个特定查询的权限（例如， 是否允许客户端对某个数据库某个表的某个操作）

二 、服务层(SQL 处理层)

这一层主要功能有： SQL 语句的解析、 优化， 缓存的查询， MySQL 内置函数的实现， 跨存储引擎功能（所谓跨存储引擎就是说每个引擎都需提供的功能（引擎需对外提供接口）， 例如： 存储过程、 触发器、 视图等。

1.如果是查询语句（select 语句） ， 首先会查询缓存是否已有相应结果， 有则返回结果， 无则进行下一步（如果不是查询语句， 同样调到下一步）

2.解析查询， 创建一个内部数据结构（解析树） ， 这个解析树主要用来 SQL语句的语义与语法解析；

3.优化： 优化 SQL 语句， 例如重写查询， 决定表的读取顺序， 以及选择需要的索引等。 这一阶段用户是可以查询的， 查询服务器优化器是如何进行优化的，便于用户重构查询和修改相关配置， 达到最优化。 这一阶段还涉及到存储引擎，优化器会询问存储引擎， 比如某个操作的开销信息、 是否对特定索引有查询优化等

缓存

show variables like '%query_cache_type%' -- 默认不开启
show variables like '%query_cache_size%' --默认值 1M
SET GLOBAL query_cache_type = 1; --会报错

query_cache_type 只能配置在 my.cnf 文件中， 这大大限制了 qc 的作用

在生产环境建议不开启， 除非经常有 sql 完全一模一样的查询.QC 严格要求 2 次 SQL 请求要完全一样， 包括 SQL 语句， 连接的数据库、 协议版本、 字符集等因素都会影响

从 8.0 开始， MySQL 不再使用查询缓存， 那么放弃它的原因是什么呢？

MySQL查询缓存是查询结果缓存。它将以SEL开头的查询与哈希表进行比较，如果匹配， 则返回上一次查询的结果。 进行匹配时， 查询必须逐字节匹配， 例如SELECT * FROM e1; 不等于 select * from e1;， 此外， 一些不确定的查询结果无法被缓存， 任何对表的修改都会导致这些表的所有缓存无效。 因此， 适用于查询缓存的最理想的方案是只读， 特别是需要检查数百万行后仅返回数行的复杂查询。如果你的查询符合这样一个特点， 开启查询缓存会提升你的查询性能。

随着技术的进步， 经过时间的考验， MySQL 的工程团队发现启用缓存的好处
并不多。

• 首先， 查询缓存的效果取决于缓存的命中率， 只有命中缓存的查询效果才能有改善， 因此无法预测其性能。
• 其次， 查询缓存的另一个大问题是它受到单个互斥锁的保护。 在具有多个内核的服务器上， 大量查询会导致大量的互斥锁争用。

通过基准测试发现， 大多数工作负载最好禁用查询缓存(5.6 的默认设置)：按照官方所说的： 造成的问题比它解决问题要多的多， 弊大于利就直接砍掉了

三 、存储引擎层

从体系结构图中可以发现， MySQL 数据库区别于其他数据库的最重要的一个特点就是其插件式的表存储引擎。MySQL 插件式的存储引擎架构提供了一系列标准的管理和服务支持， 这些标准与存储引擎本身无关， 可能是每个数据库系统本身都必需的， 如 SQL 分析器和优化器等， 而存储引擎是底层物理结构和实际文件读写的实现， 每个存储引擎开发者可以按照自己的意愿来进行开发。 需要特别注意的是， 存储引擎是基于表的， 而不是数据库。

插件式存储引擎的好处是， 每个存储引擎都有各自的特点， 能够根据具体的应用建立不同存储引擎表。 由于 MySQL 数据库的开源特性， 用户可以根据 MySQL预定义的存储引擎接口编写自己的存储引擎。 若用户对某一种存储引擎的性能或功能不满意， 可以通过修改源码来得到想要的特性， 这就是开源带给我们的方便与力量。

由于 MySQL 数据库开源特性， 存储引擎可以分为 MySQL 官方存储引擎和第三方存储引擎。 有些第三方存储引擎很强大， 如大名鼎鼎的 InnoDB 存储引擎（最早是第三方存储引擎， 后被 Oracle 收购)， 其应用就极其广泛， 甚至是 MySQL 数
据库 OLTP(Online Transaction Processing 在线事务处理）应用中使用最广泛的存储
引擎。

这篇关于MySQL 体系架构的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！