MYSQL逻辑架构

1. 逻辑架构剖析

1.1.1 MYSQL的逻辑架构—三层

MYSQL逻辑架构：一共三层。下图针对MYSQL5.0，在MYSQL8.0中没有了Cache&Buffers查询缓存。具体展开如下图：

• 连接层：Connection Pool。获取MYSQL服务层连接

• 服务层（核心）：SQL Interface（SQL接口）、Parser（解析器）、Optimizer（优化器）、Cache&Buffer（查询缓存-mysql5.0有）

• 引擎层：Pluggable Storage Engines（插件式的存储引擎）
  

  • MYSQL5.0中Cache&Buffers查询缓存：将查询结果以key-value的形式缓存，key为sql语句，value是查询结果。下次查询的sql和key完全一样，直接返回。
  • 插件式存储引擎：可以根据需要更换存储引擎，与底层文件系统进行交互。

具体查询执行顺序：

1. MYSQL客户端程序发起连接
2. 利用连接池建立连接，并分配线程处理请求
3. SQL接口：接收SQL指令
4. MYSQL5.0：查询缓存，有key直接返回（MYSQL8.0中没有这一步）
5. 缓存中没有，则在解析器中进行sql解析，并生成语法树
6. 核心：在优化器中进行逻辑优化或物理优化，物理索引是指使用索引。sql语句在语法解析之后、查询之前会使用查询优化器确定sql语句执行路径，生成一个 执行计划。
7. 调用对应的API，即存储引擎
8. 回到文件系统中进行查找(会先将物理层文件加载到内存中–buffer库缓冲池，直接与磁盘交互代价太大)
9. MYSQL5.0：将查询结果已key-value形式缓存到查询缓存
10. 最后，通过SQL接口将查询结果返回到连接池，再返回到客户端。

1.1.2 连接层—第一层

连接层：Connection Pool。获取MYSQL服务层连接

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

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

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

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

1.1.3 服务层—第二层

服务层（核心）：SQL Interface（SQL接口）、Parser（解析器）、Optimizer（优化器）、Cache&Buffer（查询缓存-mysql5.0有）

• 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： 查询缓存组件（mysql5.0有，mysql8.0无）

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

• 从MySQL 5.7.20开始，不推荐使用查询缓存，并在 MySQL 8.0中删除 。

1.1.4 引擎层—第三层

引擎层：Pluggable Storage Engines（插件式的存储引擎）

• 真正的负责了MySQL中数据的存储和提取，对 物理服务器级别维护的底层数据执行操作，服务器通过 API与存储引擎进行通信。不同的存储引擎具有的功能不同，这样我们可以根据自己的实际需要进行选取。
• MySQL 8.0.25默认支持的存储引擎如下：查询引擎语句：show engines;

2 服务器处理客户端请求—三部分

MYSQL是典型的C/S架构，即Client/Server架构，服务器端程序使用的mysqld。

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

服务器进程对客户端进程发送的请求处理过程如下图：

• 连接管理：处理客户端连接，如用户名密码校验、权限校验
• 解析与优化：解析查询语句，对sql进行优化处理
• 存储引擎：调用存储引擎，对物理层文件查找（会先将物理层文件加载到内存中–buffer库缓冲池，直接与磁盘交互代价太大）

3. SQL执行流程

3.0 SQL语法顺序

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

例：查询每个部门年龄高于20岁的人数且高于20岁人数不能少于2人，显示人数最多的第一名部门信息下面是经常出现的查询顺序：

3.1 MYSQL中的SQL执行流程

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

3.1.1 查询缓存

查询缓存： Server 如果在查询缓存中发现了这条 SQL 语句，就会直接将结果返回给客户端；如果没有，就进入到解析器阶段。

MYSQL8.0抛弃原因： 查询缓存往往效率不高，所以在 MySQL8.0 之后就抛弃了这个功能。

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

  SELECT employee_id,last_name FROM employees WHERE employee_id = 101;
  

  • 鲁棒性大大降低，只有相同的查询语句操作才会命中：上述查询语句整个作为key存储，如果下次中间多加了一个空格或者别的，会认为key不同，查询不命中，继续重新去查询。
  • 查询中有时会调用函数，如NOW()，每次调用都是当前时间，即使查询请求文本信息都一样，不同时间的两次查询也会得到不同结果。
  • 缓存失效情况：MySQL的缓存系统会监测涉及到的每张表，只要该 表的结构或者数据被修改，如对该表使用了 INSERT 、 UPDATE 、 DELETE 、 TRUNCATE TABLE 、 ALTERTABLE 、 DROP TABLE 或 DROP DATABASE 语句，那使用该表的所有高速缓存查询都将变为无效并从高速缓存中删除！对于 更新压力大的数据库 来说，查询缓存的命中率会非常低。

3.1.2. 解析器

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

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

   词法分析步骤：

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

   select department_id,job_id,avg(salary) from employees group by department_id;
   

   • 如果语法错误，会报错：

   • 如果SQL语句正确，则会生成一个这样的语法树：

3.1.3. 优化器

3.1.3.1 优化器作用

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

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

• 举例：如下语句是执行两个表的 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。
  

  这两种执行方法的逻辑结果是一样的，但是执行的效率会有不同，而优化器的作用就是决定选择使用哪一个方案。优化器阶段完成后，这个语句的执行方案就确定下来了，然后进入执行器阶段。
  优化器是怎么选择索引的，有没有可能选择错等。在后面索引部分细讲。

3.1.3.2 逻辑查询(sql等价变换)和物理查询(索引)

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

• 逻辑查询优化：通过 SQL等价变换提升查询效率，即换一种查询写法执行效率更高

    如：对条件表达式进行等价谓词重写，条件简化；对视图进行重写；对子查询进行优化；对连接语句进行外连接消除、嵌套连接消除等。
  

• 物理查询优化：通过 索引和表连接 方式等技术进行优化，重点是索引。

    如：对单表和多表连接操作，高效使用索引，提升查询效率。
  

3.1.4. 执行器

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

在执行之前需要判断该用户是否 具备权限 。 如果没有，就会返回权限错误。如果具备权限，就执行 SQL查询并返回结果。

在 MySQL8.0 以下的版本，如果设置了查询缓存，这时会将查询结果进行缓存。

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

  select * from test where id=1;
  

  如果有权限，就打开表继续执行。打开表的时候，执行器会根据表的引擎定义，调用存储引擎API对表进行的读写。存储引擎API只是抽象接口，下面还有个 存储引擎层，具体实现还要看表选择的存储引擎。

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

  至此，这个语句就执行完成了。对于有索引的表，执行的逻辑也差不多。

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

3.2. MYSQL8中SQL执行原理–实操

在MYSQL中对一条SQL语句的执行时间进行分析：

3.2.1 数据准备

在数据库中导入SQL脚本：atguigudb.sql，或者打开直接执行在database中执行

导入数据库成功：

3.2.1 确认profiling 是否开启

• 了解查询语句执行过程：查看是否开启计划。开启后可以让MYSQL收集在SQL执行所使用的资源情况，命令如下：

  select @@profiling; # 不写默认session级别
  或者
  show variables like 'profiling';
  

  

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

  

3.2.2 多次执行相同sql语句

多次执行查询语句：select * from employees;

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

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

  show profiles; # 显示最近的几次查询
  

  

3.2.4 查看profile-执行计划

• 查看执行计划，查看程序的执行步骤： show profile;

• 当然你也可以查询指定的 Query ID，比如：show profile for query 8;

• 查询 SQL 的执行时间结果和上面是一样的，因为MYSQL8.0中没有缓存Cache&Buffers，这里使用的MYSQL8.0版本。
  

  

3.2.5 查看更丰富的内容

• 以查询更丰富的内容：查看cpu、io阻塞等参数情况show profile cpu,block io for query 7;
  
• 除了查看cpu、io阻塞参数情况，还可以查询下列参数的利用情况：
  

3.3. MYSQL5.0中SQL执行原理（了解）

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

1. 配置文件中开启查询缓存
   在 /etc/my.cnf 中新增一行：query_cache_type=1

2. 重启mysql服务：systemctl restart mysqld

3. 开启查询执行计划：
   由于重启过服务，需要重新执行如下指令，开启profiling。

   set profiling=1;
   

4. 执行查询语句两次：

    select * from locations;
   

5. 查看profiles

6. 查看profile，显示执行计划，查看程序的执行步骤：show profile for query 1;
   

    show profile for query 2;
   

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

结论： 在MYSQL5.0中重复查询会先直接从缓存中获取数据

注意：

• 在MYSQL5.0中，SQL必须一致，否则不能命中缓存

  select * from department where id=10;
  select * from department where id=  10;
  

  

• 同样的开启缓存的配置信息如果在MYSQL8.0中添加，重启服务会报错。
  

• MYSQL8.0中没有query_cache参数，执行下面语句

  show variables like '%query_cache%';
  

  mysql5.0中显示：
  

  mysql8.0中显示：