MySQL逻辑架构剖析

参考链接：www.bilibili.com/video/BV1iq…

1、逻辑架构剖析

1.1、服务器处理客户端请求

首先Mysql是典型的C/S架构，服务端程序使用的是mysqld

不论客户端进程和服务端进程是采用那种方式进行通信，最后实现的效果都是：客户端进程向服务器进程发送一段文本(sql语句)，服务器进程处理后再向客户端进程发送一段文本(处理结果)

那服务器进程对客户端进程发送的请求做了什么处理，才能产生最后的处理结果呢？这里以查询请求为例展示：

下面具体展开看一下：【5.7经典结构】

Connectors：指的是不同语言中与SQL的交互【mysql服务器之外的客户端程序，与具体语言相关】。
Connection Pool：连接池，提供了多个用于客户端与服务器端交互的线程处理连接，管理缓冲用户连接，线程处理等需要缓存的需求。MySQL数据库的连接层。
Management Serveices & Utilities：系统管理和控制工具。备份、安全、复制、集群等等【基础服务组件】。
SQL Interface：接受用户的SQL命令，并且返回用户需要查询的结果。
Parser：SQL语句解析器【语法解析，语义解析，生成语法树】。
Optimizer：查询优化器，SQL语句在查询之前会使用查询优化器对查询进行优化。就是优化客户端请求query，根据客户端请求的 query 语句，和数据库中的一些统计信息，在一系列算法的基础上进行分析，得出一个最优的策略，告诉后面的程序如何取得这个 query 语句的结果。
- For Example： select uid,name from user where gender = 1;这个select 查询先根据where 语句进行选取，而不是先将表全部查询出来以后再进行gender过滤；然后根据uid和name进行属性投影，而不是将属性全部取出以后再进行过滤。最后将这两个查询条件联接起来生成最终查询结果。
Caches & Buffers：查询缓存，以key:value方式缓存查询结果【在mysql8.0中被取消了】。
Pluggable Storage Engines：插件式的存储引擎。MySQL区别于其他数据库的最重要的特点就是其插件式【拔插式】的表存储引擎(注意：存储引擎是基于表的，而不是数据库)。与底层的文件系统进行交互，**存储引擎主要是 innodb。
File System：数据落地到磁盘上，就是文件的存储。
Files&logs：日志文件

MySQL数据库和其他数据库相比，MySQL有点与众不同，它的架构可以在多种不同场景中应用并发挥良好作用。主要体现在存储引擎的架构上，插件式的存储引擎架构将查询处理和其他的系统任务以及数据的存储提取相分离。这种架构可以根据业务的需求和实际需求选择合适的存储引擎。

1.2、逻辑架构分层

1.2.1、第1层：连接层

最上层是一些客户端和连接服务，包含本地sock通信和大多数基于客户端/服务端工具实现的类似于tcp/ip的通信。主要完成一些类似于连接处理、授权认证、及相关的安全方案。在该层上引入了线程池的概念，为通过认证安全接入的客户端提供线程。同样在该层上可以实现基于SSL的安全链接。服务器也会为安全接入的每个客户端验证它所具有的操作权限。

系统（客户端）访问MySQL服务器前，做的第一件事就是建立TCP连接。

经过三次握手建立连接成功后， MySQL服务器对TCP传输过来的账号密码做身份认证、权限获取。

用户名或密码不对，会收到一个Access denied for user错误，客户端程序结束执行
用户名密码认证通过，会从权限表查出账号拥有的权限与连接关联，之后的权限判断逻辑，都将依赖于此时读到的权限

TCP 连接收到请求后，必须要分配给一个线程专门与这个客户端的交互。所以还会有个线程池，去走后面的流程。每一个连接从线程池中获取线程，省去了创建和销毁线程的开销。

1.2.2、第2层：服务层

MySQL的核心服务功能层，该层是MySQL的核心，如sql接口，包括查询缓存，解析器，解析树，预处理器，查询优化器。主要进行查询解析、分析、查询缓存、内置函数、存储过程、触发器、视图等，select操作会先检查是否命中查询缓存，命中则直接返回缓存数据，否则解析查询并创建对应的解析树。

SQL Interface: SQL接口

接收用户的SQL命令，并且返回用户需要查询的结果。比如SELECT ... FROM就是调用SQL Interface
MySQL支持DML（数据操作语言）、DDL（数据定义语言）、存储过程、视图、触发器、自定义函数等多种SQL语言接口

Parser: 解析器

在解析器中对 SQL 语句进行语法分析、语义分析。将SQL语句分解成数据结构，并将这个结构传递到后续步骤，以后SQL语句的传递和处理就是基于这个结构的。如果在分解构成中遇到错误，那么就说明这个SQL语句是不合理的。
在SQL命令传递到解析器的时候会被解析器验证和解析，并为其创建语法树，并根据数据字典丰富查询语法树，会验证该客户端是否具有执行该查询的权限。创建好语法树后，MySQL还会对SQl查询进行语法上的优化，进行查询重写。

Optimizer: 查询优化器

SQL语句在语法解析之后、查询之前会使用查询优化器确定 SQL 语句的执行路径，生成一个执行计划。这个执行计划表明应该使用哪些索引进行查询（全表检索还是使用索引检索），表之间的连接顺序如何，最后会按照执行计划中的步骤调用存储引擎提供的方法来真正的执行查询，并将查询结果返回给用户。
它使用“选取-投影-连接”策略进行查询。例如：SELECT id,name FROM student WHERE gender = '女';这个SELECT查询先根据WHERE语句进行选取，而不是将表全部查询出来以后再进行gender过滤。这个SELECT查询先根据id和name进行属性投影，而不是将属性全部取出以后再进行过滤，将这两个查询条件连接起来生成最终查询结果。

Caches & Buffers：查询缓存组件

MySQL内部维持着一些Cache和Buffer，比如Query Cache用来缓存一条SELECT语句的执行结果，如果能够在其中找到对应的查询结果，那么就不必再进行查询解析、优化和执行的整个过程了，直接将结果反馈给客户端。
这个缓存机制是由一系列小缓存组成的。比如表缓存，记录缓存，key缓存，权限缓存等
这个查询缓存可以在不同客户端之间共享。
从MySQL 5.7.20开始，不推荐使用查询缓存，并在MySQL 8.0中删除，主要就是因为命中率极低。

小故事：如果我问你9+8×16-3×2×17的值是多少，你可能会用计算器去算一下，最终结果35。如果再问你一遍9+8×16-3×2×17的值是多少，你还用再傻呵呵的再算一遍吗？我们刚刚已经算过了，直接说答案就好了。

1.2.3、第3层：引擎层

插件式存储引擎层（ Storage Engines），真正的负责了MySQL中数据的存储和提取，对物理服务器级别维护的底层数据执行操作，服务器通过API与存储引擎进行通信。不同的存储引擎具有的功能不同，这样我们可以根据自己的实际需要进行选取。

MySQL 8.0.25默认支持的存储引擎如下：

1.2.4、存储层

数据存储层，主要是将数据存储在运行于裸设备的文件系统之上，并完成与存储引擎的交互。所有的数据，数据库、表的定义，表的每一行的内容，索引，都是存在文件系统上，以文件的方式存在的，并完成与存储引擎的交互。当然有些存储引擎比如InnoDB，也支持不使用文件系统直接管理裸设备，但现代文件系统的实现使得这样做没有必要了。在文件系统之下，可以使用本地磁盘，可以使用DAS、NAS、SAN等各种存储系统。【var/lib/mysql】

1.3、小结

MySQL架构图本节开篇所示。下面为了熟悉SQL执行流程方便，我们可以简化如下：

简化为三层结构：

连接层：客户端和服务器端建立连接，客户端发送 SQL 至服务器端；
SQL 层（服务层）：对 SQL 语句进行查询处理；与数据库文件的存储方式无关；
存储引擎层：与数据库文件打交道，负责数据的存储和读取。

2、SQL性能下降的原因

性能下降导致sql慢，执行时间长，等待时间长：

查询语句写的差。
索引失效：索引建了，但是没有用上。
关联查询太多join（设计缺陷或者不得已的需求）。
服务器调优以及各个参数的设置（缓冲、线程数等）。

3、SQL执行流程

3.1、MySQL 中的 SQL执行流程

客户端向MySQL服务器发送一条查询请求
服务器先查询查询缓存，如果命中缓存，则立刻返回存储在缓存中的结果，否则进入下一阶段
服务器进行SQL解析，预处理、再由优化器生成对应的执行计划
MySQL根据执行计划，调用存储引擎的API来执行查询
将结果返回给客户端，同时缓存查询结果

以查询为主，MySQL的查询流程：

1、查询缓存：

Server 如果在查询缓存中发现了这条 SQL 语句，就会直接将结果返回给客户端；如果没有，就进入到解析器阶段。需要说明的是，因为查询缓存往往效率不高，所以在 MySQL8.0 之后就抛弃了这个功能。

大多数情况查询缓存就是个鸡肋，为什么呢？

SELECT employee_id,last_name FROM employees WHERE employee_id = 101;
复制代码

查询缓存是提前把查询结果缓存起来，这样下次不需要执行就可以直接拿到结果。需要说明的是，在MySQL 中的查询缓存，不是缓存查询计划，而是查询对应的结果。这就意味着查询匹配的鲁棒性大大降低，只有相同的查询操作才会命中查询缓存。两个查询请求在任何字符上的不同（例如：空格、注释、大小写），都会导致缓存不会命中。因此 MySQL 的查询缓存命中率不高。

那么具备命中缓存的条件是什么呢，哪些不会缓存呢？

如果查询请求中包含某些系统函数、用户自定义变量和函数、一些系统表，如 mysql、information_schema、 performance_schema 数据库中的表，那这个请求就不会被缓存。以某些系统函数举例，可能同样的函数的两次调用会产生不一样的结果，比如函数NOW ，每次调用都会产生最新的当前时间，如果在一个查询请求中调用了这个函数，那即使查询请求的文本信息都一样，那不同时间的两次查询也应该得到不同的结果，如果在第一次查询时就缓存了，那第二次查询的时候直接使用第一次查询的结果就是错误的！

此外，既然是缓存，那就有它缓存失效的时候。MySQL的缓存系统会监测涉及到的每张表，只要该表的结构或者数据被修改，如对该表使用了INSERT 、 UPDATE 、DELETE 、TRUNCATE TABLE 、ALTER TABLE 、DROP TABLE 或 DROP DATABASE 语句，那使用该表的所有高速缓存查询都将变为无效并从高速缓存中删除！对于更新压力大的数据库来说，查询缓存的命中率会非常低。

建议在静态表中使用查询缓存(即极少更新的表，如配置表、字典表)，你可以在配置文件my.cnf中将参数query_cache_type设置成DEMAND，代表当sql语句中有sql_cache关键词时才会缓存，比如

query_cache_type=2  #按需使用
复制代码

设置为2的话，这样对于默认的SQL语句都不使用查询缓存，而对于你确定要使用查询缓存的语句，可以使用sql_cache显示指定，像下面这个sql语句一样

select sql_cache * from test where ID = 5;
复制代码

查看是否开启查询缓存：

mysql> show variables like "%query_cache%";
+------------------------------+----------+
| Variable_name                | Value    |
+------------------------------+----------+
| have_query_cache             | YES      |
| query_cache_limit            | 1048576  |
| query_cache_min_res_unit     | 4096     |
| query_cache_size             | 16777216 |
| query_cache_type             | OFF       |
| query_cache_wlock_invalidate | OFF      |
+------------------------------+----------+
6 rows in set (0.00 sec)
复制代码

query_cache_type：是否开启查询缓存，0 表示不开启查询缓存，1 表示始终开启查询缓存 (不要缓存使用 sql_no_cache)， 2 表示按需开启查询缓存 (需要缓存使用sql_cache) query_cache_size：给缓存分配的最大内存空间

FLUSH QUERY CACHE ：清理查询缓存内存碎片 (不会清理查询缓存) RESET QUERY CACHE ：从查询缓存中移出所有查询 FLUSH TABLES：关闭所有打开的表，同时该操作将会清空查询缓存中的内容

案列演示：开启查询缓存后的sql语句执行效果

[root@localhost www]# find / -name my.cnf
/etc/my.cnf

[root@localhost www]# vim /etc/my.cnf

添加query_cache_type=1

[root@localhost www]# systemctl restart mysqld
复制代码

查询结果：

#开启查询缓存之前
SELECT * from purchase_order WHERE order_sn like "ry2bhxtAu4%"
> OK
> 时间: 2.674s

#开启查询缓存之后
SELECT * from purchase_order WHERE order_sn like "ry2bhxtAu4%"
> OK
> 时间: 0.002s
复制代码

2、解析器：

在解析器中对 SQL 语句进行语法分析、语义分析。

分析器先做“ 词法分析”。你输入的是由多个字符串和空格组成的一条 SQL 语句，MySQL 需要识别出里面的字符串分别是什么，代表什么。 MySQL 从你输入的"select"这个关键字识别出来，这是一个查询语句。它也要把字符串“T”识别成“表名 T”，把字符串“ID”识别成“列ID”。

接着，要做“ 语法分析”。根据词法分析的结果，语法分析器（比如：Bison）会根据语法规则，判断你输入的这个 SQL 语句是否满足 MySQL 语法。

select department_id,job_id,avg(salary) from employees group by department_id;
复制代码

语句不对就会报错，如果SQL语句正确，则会生成一个这样的语法树：

sql词法分析的过程步骤：

3、优化器：

在优化器中会确定 SQL 语句的执行路径，比如是根据全表检索，还是根据索引检索等。

经过了解析器，mysql就知道要做什么了，在sql语句开始执行之前，还要先经过优化器的处理，一条查询语句可以有很多种可以返回相同结果的执行方式，优化器的作用就是找到这其中最好的执行计划。

举例：如下语句是执行两个表的 join：

select * from test1 join test2 using(ID)
where test1.name='zhangwei' and test2.name='mysql高级课程';
复制代码

方案1：可以先从表 test1 里面取出 name='zhangwei'的记录的 ID 值，再根据 ID 值关联到表 test2，再判断 test2 里面 name的值是否等于 'mysql高级课程'。

方案2：可以先从表 test2 里面取出 name='mysql高级课程' 的记录的 ID 值，再根据 ID 值关联到 test1，再判断 test1 里面 name的值是否等于 zhangwei。

这两种执行方法的逻辑结果是一样的，但是执行的效率会有不同，而优化器的作用就是决定选择使用哪一个方案。优化器阶段完成后，这个语句的执行方案就确定下来了，然后进入执行器阶段。

如果你还有一些疑问，比如优化器是怎么选择索引的，有没有可能选择错等。后面讲到索引我们再谈。

在查询优化器中，可以分为逻辑查询优化阶段和物理查询优化阶段。

4、执行器：

截止到现在，还没有真正去读写真实的表，仅仅只是产出了一个执行计划。于是就进入了执行器阶段。

在执行之前需要判断该用户是否具备权限。如果没有，就会返回权限错误。如果具备权限，就执行 SQL查询并调用相应表的存储引擎API查询并且返回结果(存储引擎API只是抽象接口，下面还有个存储引擎层，具体实现还是要看表选择的存储引擎)。在 MySQL8.0 以下的版本，如果设置了查询缓存，这时会将查询结果进行缓存。

select * from test where id=1;
复制代码

比如：表 test 中，ID 字段没有索引，那么执行器的执行流程是这样的：

调用 InnoDB 引擎接口取这个表的第一行，判断 ID 值是不是1，如果不是则跳过，如果是则将这行存在结果集中；调用引擎接口取“下一行”，重复相同的判断逻辑，直到取到这个表的最后一行。执行器将上述遍历过程中所有满足条件的行组成的记录集作为结果集返回给客户端。 至此，这个语句就执行完成了。对于有索引的表，效率更高，但是执行的逻辑也差不多。

3.2、小结：Sql语句的查询流程

SQL 语句在 MySQL 中的流程是： SQL语句→查询缓存→解析器→优化器→执行器。

mysql 的查询流程具体来说是：

mysql 客户端通过协议与mysql 服务器建连接，发送查询语句，先检查查询缓存，如果命中，直接返回结果，否则进行语句解析,也就是说，在解析查询之前，服务器会先访问查询缓存(query cache)——它存储SELECT 语句以及相应的查询结果集。如果某个查询结果已经位于缓存中，服务器就不会再对查询进行解析、优化、以及执行。它仅仅将缓存中的结果返回给用户即可，这将大大提高系统的性能。

语法解析器和预处理：

首先mysql通过关键字将SQL语句进行解析，并生成一颗对应的“解析树”。mysql 解析器将使用mysql 语法规则验证和解析查询；预处理器则根据一些mysql规则进一步检查解析数是否合法。

查询优化器：

当解析树被认为是合法的了，并且由优化器将其转化成执行计划。一条查询可以有很多种执行方式，最后都返回相同的结果。优化器的作用就是找到这其中最好的执行计划。

然后，执行器：mysql 默认使用的B TREE 索引，并且一个大致方向是：无论怎么折腾sql，至少在目前来说，mysql 最多只用到表中的一个索引。

3.3、MySQL8中SQL执行原理

为了了解mysql查询语句执行的过程，可以通过select @@profiling;或者show variables like 'profiling';查看是否开启计划，开启它可以让mysql收集在sql执行时所使用的资源情况

确认profiling 是否开启

mysql> select @@profiling;
mysql> show variables like 'profiling';
复制代码

profiling=0 代表关闭，我们需要把 profiling 打开，即设置为 1：

mysql> set profiling=1;
复制代码

2、多次执行相同SQL查询

然后我们执行一个 SQL 查询（你可以执行任何一个 SQL 查询）：

mysql> select * from employees;
复制代码

3、查看profiles

查看当前会话所产生的所有 profiles：

mysql> show profiles; # 显示最近的几次查询
复制代码

4、查看profile

显示执行计划，查看程序的执行步骤：

mysql> show profile; # 显示最近的1次查询
复制代码

当然你也可以查询指定的 Query ID，根据Query_ID,可以进一步执行show profile cpu,block io for query Query_id 来查看sql 的具体执行步骤。

比如：

mysql> show profile for query 7;
复制代码

查询 SQL 的执行时间结果和上面是一样的。

此外，还可以查询更丰富的内容：

mysql> show profile cpu,block io for query 6;
复制代码

继续：

mysql> show profile cpu,block io for query 7;
复制代码

可以发现两次都是一样的，所以是没有开启查询缓存的，

上述操作在MySQL5.7中测试，发现前后两次相同的sql语句，执行的查询过程仍然是相同的。不是会使用缓存吗？这里我们需要显式开启查询缓存模式。在MySQL5.7中如下设置：

1、配置文件中开启查询缓存

在 /etc/my.cnf 中新增一行：

query_cache_type=1
复制代码

2、重启mysql服务

systemctl restart mysqld
复制代码

3、开启查询执行计划

由于重启过服务，需要重新执行如下指令，开启profiling。

mysql> set profiling=1;
复制代码

4、执行语句两次：

mysql> select * from locations;
mysql> select * from locations;
复制代码

5、查看profiles

6、查看profile

显示执行计划，查看程序的执行步骤：

mysql> show profile for query 1;
复制代码

mysql> show profile for query 2;
复制代码

结论不言而喻。执行编号2时，比执行编号1时少了很多信息，从截图中可以看出查询语句直接从缓存中获取数据。

注意

sql必须是一致的，否则，不能命中缓存
同样开启缓存的配置信息在Mysql8中添加，重启服务时会出错

3.4、SQL语法顺序

随着Mysql版本的更新换代，其优化器也在不断的升级，优化器会分析不同执行顺序产生的性能消耗不同而动态调整执行顺序。

需求：查询每个部门年龄高于20岁的人数且高于20岁人数不能少于2人，显示人数最多的第一名部门信息

下面是经常出现的查询顺序：

总结：

4、七种JOIN理论

七种JOIN理论

5、数据库缓冲池(buffer pool)

InnoDB 存储引擎是以页为单位来管理存储空间的，我们进行的增删改查操作其实本质上都是在访问页面（包括读页面、写页面、创建新页面等操作）。而磁盘 I/O 需要消耗的时间很多，而在内存中进行操作，效率则会高很多，为了能让数据表或者索引中的数据随时被我们所用，DBMS 会申请占用内存来作为数据缓冲池，在真正访问页面之前，需要把在磁盘上的页缓存到内存中的Buffer Pool 之后才可以访问。

这样做的好处是可以让磁盘活动最小化，从而减少与磁盘直接进行 I/O 的时间。要知道，这种策略对提升 SQL 语句的查询性能来说至关重要。如果索引的数据在缓冲池里，那么访问的成本就会降低很多。

5.1 缓冲池 vs 查询缓存

缓冲池和查询缓存是一个东西吗？不是。

1、缓冲池（Buffer Pool）

首先我们需要了解在 InnoDB 存储引擎中，缓冲池都包括了哪些。

在 InnoDB 存储引擎中有一部分数据会放到内存中，缓冲池则占了这部分内存的大部分，它用来存储各种数据的缓存，如下图所示：

从图中，你能看到 InnoDB 缓冲池包括了数据页、索引页、插入缓冲、锁信息、自适应 Hash 和数据字典信息等。

缓存原则：

“位置 * 频次”这个原则，可以帮我们对 I/O 访问效率进行优化。

首先，位置决定效率，提供缓冲池就是为了在内存中可以直接访问数据。

其次，频次决定优先级顺序。因为缓冲池的大小是有限的，比如磁盘有 200G，但是内存只有 16G，缓冲池大小只有 1G，就无法将所有数据都加载到缓冲池里，这时就涉及到优先级顺序，会优先对使用频次高的热数据进行加载。

2、查询缓存

那么什么是查询缓存呢？

查询缓存是提前把查询结果缓存起来，这样下次不需要执行就可以直接拿到结果。需要说明的是，在MySQL 中的查询缓存，不是缓存查询计划，而是查询对应的结果。因为命中条件苛刻，而且只要数据表发生变化，查询缓存就会失效，因此命中率低。

5.2 缓冲池如何读取数据

缓冲池管理器会尽量将经常使用的数据保存起来，在数据库进行页面读操作的时候，首先会判断该页面是否在缓冲池中，如果存在就直接读取，如果不存在，就会通过内存或磁盘将页面存放到缓冲池中再进行读取。

缓存在数据库中的结构和作用如下图所示：

如果我们执行 SQL 语句的时候更新了缓存池中的数据，那么这些数据会马上同步到磁盘上吗？

5.3 查看/设置缓冲池的大小

如果你使用的是 InnoDB 存储引擎，可以通过查看 innodb_buffer_pool_size 变量来查看缓冲池的大小。命令如下：

show variables like 'innodb_buffer_pool_size';
复制代码

你能看到此时 InnoDB 的缓冲池大小只有 134217728/1024/1024=128MB。我们可以修改缓冲池大小，比如改为256MB，方法如下：

set global innodb_buffer_pool_size = 268435456;
复制代码

或者：

[server]
innodb_buffer_pool_size = 268435456
复制代码

然后再来看下修改后的缓冲池大小，此时已成功修改成了 256 MB：

5.4 多个Buffer Pool实例

[server]
innodb_buffer_pool_instances = 2
复制代码

这样就表明我们要创建2个Buffer Pool 实例。

我们看下如何查看缓冲池的个数，使用命令：

show variables like 'innodb_buffer_pool_instances';
复制代码

那每个Buffer Pool 实例实际占多少内存空间呢？其实使用这个公式算出来的：

innodb_buffer_pool_size/innodb_buffer_pool_instances
复制代码

也就是总共的大小除以实例的个数，结果就是每个Buffer Pool 实例占用的大小。

5.5 引申问题

Buffer Pool是MySQL内存结构中十分核心的一个组成，你可以先把它想象成一个黑盒子。

黑盒下的更新数据流程

当我们查询数据的时候，会先去buffer pool中不存在，存储引擎会先将数据从磁盘加载到buffer pool中，然后将数据返回给客户端，同理，当我们更新某个数据的时候，如果这个数据不存在于Buffer pool，同样会先将数据加载进来，然后修改内存中的数据，被修过的数据会在之后统一刷入磁盘

再者，我更新到一半突然发生错误了，想要回滚到更新之前的版本，该怎么办？连数据持久化的保证、事务回滚都做不到还谈什么崩溃恢复？

答案：Redo Log & Undo Log

高级篇(day04)-MySQL逻辑架构剖析