MySQL 高级 - 第五章 | 逻辑架构

向右看齐 2024-05-06 23:21 63阅读 0赞

#### 目录 ####

*  一、逻辑架构的剖析
 *   *  1.1 服务器处理客户端请求
     *  1.2 客户端连接器
     *  1.3 MySQL Server 的三层架构
     *   *  1.3.1 第一层：连接层
         *  1.3.2 第二层：服务层
         *  1.3.3 第三层：存储引擎层
 *  二、SQL 执行流程
 *   *  2.1 MySQL 中的 SQL 执行流程
     *  2.2 SQL 执行原理
     *   *  2.2.1 查询资源使用情况
         *  2.2.2 MySQL-5.7 中的 SQL 执行原理
         *  2.2.3 MySQL-8.0 中的 SQL 执行原理
         *  2.2.4 SQL 语法顺序
         *  2.2.5 Oracle 中的 SQL 执行流程
 *  三、数据库缓冲池
 *   *  3.1 缓冲池 & 查询缓存
     *  3.2 缓冲池如何读取数据
     *  3.3 查看设置缓冲池的大小
     *  3.4 多个 Buffer Pool 实例
     *  3.5 引申问题

--------------------

上篇：[第四章、配置文件与系统变量][Link 1]  
下篇：[第六章、存储引擎][Link 2]

本文内容主要源于：[bilibili-尚硅谷-MySQL高级篇][bilibili-_-MySQL]

## 一、逻辑架构的剖析 ##

--------------------

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

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

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

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

![在这里插入图片描述][07908bf0a2714820a44c24abe3abbcfa.png]

具体流程（针对于 `MySQL-5.7`）：

![bb9b851a0b605c22d74be72b6a01b90d.png_pic_center][]

在 `MySQL-8.0` 版本中 `缓存` 被移除了

--------------------

### 1.2 客户端连接器 ###

客户端连接器（`Connectors`）指的是不同语言中与 `SQL` 的交互，`MySQL` 首先是一个网络程序，在 `TCP` 之上定义了自己的应用层协议，所以要使用 `MySQ`L，可以编写代码跟 `MySQL` 建立 `TCP` 连接，之后按照其定义好的协议进行交互或者比较方便的办法是调用 `SDK`，比如 `Native C API`、`JDBC`、`PHP` 等各个语言 `MySQL Connector`，或者通过 `ODBC`，但通过 `SDK` 来访问 `MySQL` 本质上还是在 `TCP` 连接上通过 `MySQL` 协议跟 `MySQL` 进行交互。

--------------------

### 1.3 MySQL Server 的三层架构 ###

![在这里插入图片描述][134608d365c447508142bf975a8999f4.png]

简化为三层结构：

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

--------------------

#### 1.3.1 第一层：连接层 ####

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

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

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

一个系统只会和 `MySQL` 服务器建立一个连接吗？只能有一个系统和 `MySQL` 服务器建立连接吗？

当然不是，多个系统都可以和 `MySQL` 服务器建立连接，每个系统建立的连接肯定不止一个，所以为了解决 `TCP` 无限创建与 `TCP` 频繁创建销毁带来的资源耗尽、性能下降问题。`MySQL` 服务器有专门的 `TCP 连接池` 限制连接数。

采用 `长连接模式复用 TCP` 连接来解决上述问题。

![在这里插入图片描述][e502db57fadc4f4ca033cb0cf50d716f.png]

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

所以 `连接管理` 的职责就是负责管理连接、账号认证和获取权限信息。

--------------------

#### 1.3.2 第二层：服务层 ####

第二层架构主要完成大多数的核心服务功能，如 `SQL` 接口，并完成 缓存的查询，`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` 过滤，根据 `id` 和 `name` 进行属性 `投影`，而不是将属性全部取出以后再进行过滤，将这两个查询条件 `连接` 起来生成最终查询结构
 *  `Cache & Buffers`：查询缓存组件
    
     *  `MySQL` 内部维持着一些 `Cache` 和 `Buffer`，比如 `Query Cache` 用来缓存一条 `SELECT` 语句的执行结果，如果能够在其中找到对应的查询结果，那么就不必再进行查询解析、优化和执行的整个过程了，直接将结果反馈给客户端
     *  这个缓存机制是由一系列小缓存组成的，比如表缓存、记录缓存、`key` 缓存、权限缓存等
     *  这个查询缓存可以在 `不同客户端之间共享`
     *  从 `MySQL-5.7.20` 开始，不推荐使用查询缓存，并在 `MySQL-8.0` 中删除

--------------------

#### 1.3.3 第三层：存储引擎层 ####

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

这种高效的模块化架构为那些希望专门针对特定应用程序需求（例如数据仓库、事务处理或可用性情况）的人提供了巨大的好处，同时享受使用一组独立于任何接口和服务的优势存储引擎。

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

可以用以下命令查看 `MySQL` 所支持的存储引擎

SHOW ENGINES;

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

mysql> SHOW ENGINES;
    +--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
    | Engine             | Support | Comment                                                        | Transactions | XA   | Savepoints |
    +--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
    | FEDERATED          | NO      | Federated MySQL storage engine                                 | NULL         | NULL | NULL       |
    | MEMORY             | YES     | Hash based, stored in memory, useful for temporary tables      | NO           | NO   | NO         |
    | InnoDB             | DEFAULT | Supports transactions, row-level locking, and foreign keys     | YES          | YES  | YES        |
    | PERFORMANCE_SCHEMA | YES     | Performance Schema                                             | NO           | NO   | NO         |
    | MyISAM             | YES     | MyISAM storage engine                                          | NO           | NO   | NO         |
    | MRG_MYISAM         | YES     | Collection of identical MyISAM tables                          | NO           | NO   | NO         |
    | BLACKHOLE          | YES     | /dev/null storage engine (anything you write to it disappears) | NO           | NO   | NO         |
    | CSV                | YES     | CSV storage engine                                             | NO           | NO   | NO         |
    | ARCHIVE            | YES     | Archive storage engine                                         | NO           | NO   | NO         |
    +--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
    9 rows in set (0.00 sec)

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

--------------------

## 二、SQL 执行流程 ##

--------------------

### 2.1 MySQL 中的 SQL 执行流程 ###

![在这里插入图片描述][cf2fc378b7cb4075bea466c50e01e4a2.png]

`MySQL` 的查询流程：

*  ① 查询缓存
 *  ② 解析器
 *  ③ 优化器
 *  ④ 执行器

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

![在这里插入图片描述][5c43a6a3461142feaa19ac3116b6f6ae.png]

`MySQL` 拿到一个查询请求后，会先到查询缓存看看，之前是不是执行过这条语句，之前执行过的语句及其结果可能会以 `key-value` 键值对的形式被直接缓存在内存中，`key` 是查询语句，`value` 是查询的结果。如果你的查询能够直接在这个缓存中找到 `key`，那么这个 `value` 就会被直接返回给客户端。如果语句不在查询缓存中，就会继续后面的执行阶段。执行完成后，执行结果会被存入查询缓存中，所以，如果查询命中缓存，`MySQL` 不需要执行后面的复杂操作，就可以直接返回结果，这个效率会很高。

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

比如：

SELECT id,name FROM t_user where id = 1;
    
    # 即使该 SQL 只比上一条 SQL 多一个空格，也会未命中缓存
    SELECT id, name FROM t_user where id = 1;

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

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

总之，因为查询缓存往往弊大于利，查询缓存的失效非常频繁

一般建议在静态表里使用查询缓存，什么叫 `静态表` 呢？就是一般极少更新的表。比如，一个系统配置表、字典表、这张表上的查询才适合使用查询缓存。好在 `MySQL` 也提供了这种 按需使用 的方式，可以将 `my.cnf` 参数 `query_cache_type` 设置成 `DEMAND`，代表当 `SQL` 语句中有 `SQL_CACHE` 关键词时才缓存，比如：

# query_cache_type 有 3 个值：0 表示关闭查询缓存 OFF，1 代表开启，2 表示 DEMAND
    query_cache_type=2

这样对于默认的 `SQL` 语句都不使用查询缓存，而对于你确定要使用查询缓存的语句，可以用 `SQL_CACHE` 显示指定，像下面这个语句一样：

SELECT SQL_CACHE * FROM table_name WHERE ...;

不使用查询缓存也可以写作

SELECT SQL_NO_CACHE * FROM table_name WHERE ...;

查看当前 `MySQL` 实例是否开启缓存机制

# MySQL-5.7 中，在默认情况下 MySQL 也是关闭的
    mysql>SHOW GLOBAL VARIABLES LIKE '%query_cache_type%';
    +---------------------------+---------+
    | Variable_name             | Vaule   |
    +---------------------------+---------+
    | Query_cache_type          | OFF     |
    +--------------------+----------------+
    1 rows in set (0.00 sec)
    
    # MySQL-8.0 中不存在该参数
    mysql> SHOW GLOBAL VARIABLES LIKE '%query_cache_type%';
    Empty set (0.00 sec)

监控查询缓存命中率：

mysql> SHOW STATUS LIKE '%Qcache%';
    +---------------------------+---------+
    | Variable_name             | Vaule   |
    +---------------------------+---------+
    | Qcahce_free_blocks        | 1       |
    | Qcahce_free_memory        | 1031832 |
    | Qcahce_hits               | 0       |
    | Qcahce_inserts            | 0       |
    | Qcahce_lowmem_prunes      | 0       |
    | Qcahce_not_cached         | 1280    |
    | Qcahce_queries_incahce    | 0       |
    | Qcahce_total_blocks       | 1       |
    +--------------------+----------------+
    9 rows in set (0.00 sec)

运行结果分析：

*  `Qcahce_free_blocks`：表示查询缓存中还有多少个剩余的 `blocks`，如果该值显示较大，则说明查询缓存中的 `内存碎片` 过多了，可能在一定的时间进行整理
 *  `Qcahce_free_memory`：查询缓存的内存大小，通过这个参数可以很清晰的知道当前系统的查询内存是否够用，是多了，还是不够用，DBA 可以根据实际情况做出调整
 *  `Qcahce_hits`：表示有 `多少次命中缓存`，主要可以通过该值来验证查询缓存的效果，数字越大，缓存效果越理想
 *  `Qcahce_inserts`：表示 `多少次未命中然后加入`，意思是新来的 `SQL` 请求在缓存中未找到，不得不执行查询处理，执行查询处理后把结果 insert 到查询缓存中，这样的情况的次数越多，表示查询缓存应用到的比较少，效果也就不理想，当然系统刚启动后，查询缓存是空的，也很正常
 *  `Qcahce_lowmem_prunes`：该参数记录有 `多少条查询因为内存不足而被移除` 出查询缓存，通过这个值，用户可以适当的调整缓存大小
 *  `Qcahce_not_cached`：表示因为 `query_cache_type` 的设置而没有被缓存的查询数量
 *  `Qcahce_queries_incahce`：当前缓存中 `缓存的查询数量`
 *  `Qcahce_total_blocks`：当前缓存的 `block` 数量

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

![在这里插入图片描述][286687da8c594eebb8b519b53db7aedd.png]  
如果没有命中查询缓存，就要开始真正执行语句了，首先，`MySQL` 需要知道你要做什么，因此需要对 `SQL` 语句进行解析，`SQL` 语句的分析分为 `词法分析` 和 `语法分析`。

分析器先做 `词法分析`，你输入的是由多个字符串和空格组成的一条 `SQL` 语句，`MySQL` 需要识别出里面的字符串分别是什么，代表什么。

`MySQL` 从你输入的 `select` 这个关键字就能判断这是一个查询语句，并把所需要查询的表、列都识别出来

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

如果你的语句不对，就会提示 `You have an error in your SQL syntax` 的错误提醒，比如下面这个语句将 `from` 写成 `fro`

mysql> select * fro t_user where id = 1;
    ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'fro t_user where id = 1' at line 1

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

![在这里插入图片描述][bdf8ede4c59749c48e5b2477e79ce55c.png]

下图是 `SQL` 语法分析的过程步骤：

![在这里插入图片描述][969f09bc4d4441d994215e382a55ccb5.png]

至此解析器的工作任务也算基本圆满了，接下来进入到优化器

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

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

![在这里插入图片描述][9ad117757ed54fd6bf0f3615d9b591dd.png]

比如：优化器是在表里面有多个索引的时候，决定使用哪个索引，或者在一个语句有多表关联（`join`）的时候，决定各个表的连接顺序，还有表达式简化，子查询转为连接，外连接转为内连接等

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

select * from test1 join test2 using(ID)
    where test1.name = 'duojiala' and test2.name = '泰酷啦';

*  方案一：可以先从表 `test1` 里面取出 `name = 'duojiala'` 的记录 `ID` 值，再根据 `ID` 值关联到表 `test2`，再判断 `test2` 里面 `name` 的值是否等于 `泰酷啦`
 *  方案二：可以先从表 `test2` 里面取出 `name = '泰酷啦'` 的记录 `ID` 值，再根据 `ID` 值关联到表 `test1`，再判断 `test1` 里面 `name` 的值是否等于 `duojiala`

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

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

逻辑查询优化就是通过改变 `SQL` 语句的内容来使得 `SQL` 查询更高效，同时为物理查询优化提供更多的候选执行计划。通常采用的方式是对 `SQL` 语句进行 `等价变换`，对查询进行 `重写`，而查询重写的数学基础就是关系代数，对条件表达式进行等价谓词重写、条件简化，对视图进行重写，对子查询进行优化，对连接语义进行外连接消除、嵌套连接消除等

物理查询优化是基于关系代数进行的查询重写，而关系代数的每一步都对应着物理计算，这些物理计算往往存在多种算法，因此需要计算各种物理路径的代价，从中选择代价最小的作为执行计划，在这个阶段里，对于单表和多表连接的操作，需要高效地 `使用索引`，提升查询效率。

**4. 执行器：**

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

![在这里插入图片描述][88f713deb0ad4d88981361a67ca68500.png]

在执行之前需要判断该用户是否 `具备权限`。如果没有，就会返回权限错误，如果具备权限，就执行 `SQL` 查询并返回结果，在 `MySQL-8.0` 以下的版本，如果设置了查询缓存，这时会将查询结果进行缓存。

select * from test where id = 1;

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

![在这里插入图片描述][8189ebb3c94b4982ac2da1c6b1e6b2a8.png_pic_center]

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

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

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

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

![在这里插入图片描述][8014b3eb4b4b48c38534b0155e7843c3.png]

--------------------

### 2.2 SQL 执行原理 ###

--------------------

#### 2.2.1 查询资源使用情况 ####

不同的 `DBMS` 其 `SQL` 的执行原理是相通的，只是在不同的软件中，各有各的实现路径。

一条 `SQL` 语句会经历不同的模块，可以用 `show profile` 命令查看在不同模块中 `SQL` 执行所使用的资源（时间）。

`MySQL` 默认情况下是不会开启 `profiling` 的，可以通过以下命令确认是否开启计划：

select @@profiling;
    
    show variables like '%profiling%';

示例：

`profiling` 为 `0` 或者 `OFF`，表示关闭

如果想让 `MySQL` 收集在 `SQL` 执行时所使用的资源情况，则需要把 `profiling` 打开，即设置为 `1`；

mysql> SET profiling = 1;
    Query OK, 0 rows affected, 1 warning (0.00 sec)

`show profile` 基本语法：

show profile [type [, type] ...] [for Query_ID] [LIMIT row_count [OFFSET offset]]

type 可设置的值有：

*  `ALL`：显示所有参数的开销信息
 *  `BLOCK IO`：显示 `IO` 的相关开销
 *  `CONTEXT SWITCHES`：上下文切换相关开销
 *  `CPU`：显示 `CPU` 相关开销信息
 *  `IPC`：显示发送和接收相关开销信息
 *  `MEMORY`：显示内存相关开销信息
 *  `PAGE FALUTS`：显示页面错误相关开销信息
 *  `SOURCE`：显示 `Source_function，Source_file，Source_line` 相关的开销信息
 *  `SWAPS`：显示交换次数相关的开销信息

展示所有 `SQL` 语句的简要耗时情况：

show profiles;

示例：

mysql> show profiles;
    +----------+------------+----------------------------+
    | Query_ID | Duration   | Query                      |
    +----------+------------+----------------------------+
    |        1 | 0.00030500 | select * from t_access_log |
    |        2 | 0.00027300 | select * from t_access_log |
    +----------+------------+----------------------------+
    2 rows in set, 1 warning (0.00 sec)

查询最近一条 `SQL` 的详细耗时信息

show profile;

示例：

mysql> show profile;
    +--------------------------------+----------+
    | Status                         | Duration |
    +--------------------------------+----------+
    | starting                       | 0.000066 |
    | Executing hook on transaction  | 0.000004 |
    | starting                       | 0.000008 |
    | checking permissions           | 0.000006 |
    | Opening tables                 | 0.000032 |
    | init                           | 0.000006 |
    | System lock                    | 0.000009 |
    | optimizing                     | 0.000005 |
    | statistics                     | 0.000013 |
    | preparing                      | 0.000015 |
    | executing                      | 0.000068 |
    | end                            | 0.000003 |
    | query end                      | 0.000003 |
    | waiting for handler commit     | 0.000007 |
    | closing tables                 | 0.000007 |
    | freeing items                  | 0.000012 |
    | cleaning up                    | 0.000010 |
    +--------------------------------+----------+
    17 rows in set, 1 warning (0.00 sec)

这里默认查询的就是 `Query_ID = 2` 的这条 `SQL`

![在这里插入图片描述][6a18fcd3e2124f6591de625f4fb9c5c0.png]

当然也可以查询指定 `SQL` 的执行过程，语法如下：

show profile for query Query_ID;

示例：

mysql> show profile for query 1;
    +--------------------------------+----------+
    | Status                         | Duration |
    +--------------------------------+----------+
    | starting                       | 0.000064 |
    | Executing hook on transaction  | 0.000006 |
    | starting                       | 0.000008 |
    | checking permissions           | 0.000006 |
    | Opening tables                 | 0.000031 |
    | init                           | 0.000005 |
    | System lock                    | 0.000010 |
    | optimizing                     | 0.000004 |
    | statistics                     | 0.000014 |
    | preparing                      | 0.000015 |
    | executing                      | 0.000070 |
    | end                            | 0.000016 |
    | query end                      | 0.000004 |
    | waiting for handler commit     | 0.000008 |
    | closing tables                 | 0.000007 |
    | freeing items                  | 0.000020 |
    | cleaning up                    | 0.000020 |
    +--------------------------------+----------+
    17 rows in set, 1 warning (0.00 sec)

如果想要查询 `CPU`、`io` 阻塞等参数情况，可以写作：

# 查看指定 SQL 的 CPU、io 阻塞等参数情况 
    mysql> show profile cpu,block io for query 1;
    +--------------------------------+----------+----------+------------+--------------+---------------+
    | Status                         | Duration | CPU_user | CPU_system | Block_ops_in | Block_ops_out |
    +--------------------------------+----------+----------+------------+--------------+---------------+
    | starting                       | 0.000064 | 0.000062 |   0.000000 |            0 |             0 |
    | Executing hook on transaction  | 0.000006 | 0.000006 |   0.000000 |            0 |             0 |
    | starting                       | 0.000008 | 0.000008 |   0.000000 |            0 |             0 |
    | checking permissions           | 0.000006 | 0.000006 |   0.000000 |            0 |             0 |
    | Opening tables                 | 0.000031 | 0.000021 |   0.000009 |            0 |             0 |
    | init                           | 0.000005 | 0.000003 |   0.000002 |            0 |             0 |
    | System lock                    | 0.000010 | 0.000006 |   0.000004 |            0 |             0 |
    | optimizing                     | 0.000004 | 0.000003 |   0.000001 |            0 |             0 |
    | statistics                     | 0.000014 | 0.000009 |   0.000005 |            0 |             0 |
    | preparing                      | 0.000015 | 0.000010 |   0.000005 |            0 |             0 |
    | executing                      | 0.000070 | 0.000045 |   0.000024 |            0 |             0 |
    | end                            | 0.000016 | 0.000007 |   0.000004 |            0 |             0 |
    | query end                      | 0.000004 | 0.000000 |   0.000000 |            0 |             0 |
    | waiting for handler commit     | 0.000008 | 0.000005 |   0.000003 |            0 |             0 |
    | closing tables                 | 0.000007 | 0.000005 |   0.000002 |            0 |             0 |
    | freeing items                  | 0.000020 | 0.000013 |   0.000007 |            0 |             0 |
    | cleaning up                    | 0.000020 | 0.000013 |   0.000007 |            0 |             0 |
    +--------------------------------+----------+----------+------------+--------------+---------------+
    17 rows in set, 1 warning (0.00 sec)

--------------------

#### 2.2.2 MySQL-5.7 中的 SQL 执行原理 ####

因为 `MySQL-5.7` 在默认情况下是不使用缓存的

所有需要开启查询缓存的设置，在配置文件 `my.cnf` 中添加以下设置：

[mysqld]
    # query_cache_type 有 3 个值：0 表示关闭查询缓存 OFF，1 代表开启，2 表示 DEMAND
    query_cache_type=2

再重启 `MySQL` 服务器

这里我 `mike_inner` 库下有一个 `t_access_log` 的表，我对于该表进行两次查询操作

示例：

mysql> use mike_inner;
    Reading table information for completion of table and column names
    You can turn off this feature to get a quicker startup with -A
    
    Database changed
    
    mysql> SET profiling = 1;
    Query OK, 0 rows affected, 1 warning (0.00 sec)
    
    mysql> select * from t_access_log;
    +----+------------+-------------+-----------------+---------------------+-------+
    | id | login_name | access_path | access_ip       | create_time         | state |
    +----+------------+-------------+-----------------+---------------------+-------+
    |  1 | duojiala   | /auth/login | 192.168.110.193 | 2024-04-18 09:15:28 |     0 |
    |  2 | caodali    | /auth/login | 192.168.110.193 | 2024-04-18 09:16:27 |     1 |
    +----+------------+-------------+-----------------+---------------------+-------+
    2 rows in set (0.00 sec)
    
    mysql> select * from t_access_log;
    +----+------------+-------------+-----------------+---------------------+-------+
    | id | login_name | access_path | access_ip       | create_time         | state |
    +----+------------+-------------+-----------------+---------------------+-------+
    |  1 | duojiala   | /auth/login | 192.168.110.193 | 2024-04-18 09:15:28 |     0 |
    |  2 | caodali    | /auth/login | 192.168.110.193 | 2024-04-18 09:16:27 |     1 |
    +----+------------+-------------+-----------------+---------------------+-------+
    2 rows in set (0.00 sec)
    
    mysql> show profiles;
    +----------+------------+----------------------------+
    | Query_ID | Duration   | Query                      |
    +----------+------------+----------------------------+
    |        1 | 0.00030500 | select * from t_access_log |
    |        2 | 0.00027300 | select * from t_access_log |
    +----------+------------+----------------------------+
    2 rows in set, 1 warning (0.00 sec)
    
    mysql> show profile for query 1;
    +--------------------------------+----------+
    | Status                         | Duration |
    +--------------------------------+----------+
    | starting                       | 0.000064 |
    | Waiting for query cache lock   | 0.000006 |
    | starting                       | 0.000008 |
    | Checking query cahce for query | 0.000051 |
    | checking permissions           | 0.000006 |
    | Opening tables                 | 0.000031 |
    | init                           | 0.000005 |
    | System lock                    | 0.000010 |
    | Waiting for query cache lock   | 0.000006 |
    | System lock                    | 0.000010 |
    | optimizing                     | 0.000004 |
    | statistics                     | 0.000014 |
    | preparing                      | 0.000015 |
    | executing                      | 0.000070 |
    | Sending data                   | 0.000070 |
    | end                            | 0.000016 |
    | query end                      | 0.000004 |
    | closing tables                 | 0.000004 |
    | freeing items                  | 0.000004 |
    | Waiting for query cache lock   | 0.000006 |
    | freeing items                  | 0.000004 |
    | Waiting for query cache lock   | 0.000006 |
    | freeing items                  | 0.000004 |
    | storing result in query cache  | 0.000020 |
    | cleaning up                    | 0.000020 |
    +--------------------------------+----------+
    25 rows in set, 1 warning (0.00 sec)
    
    mysql> show profile for query 2;
    +--------------------------------+----------+
    | Status                         | Duration |
    +--------------------------------+----------+
    | starting                       | 0.000066 |
    | Waiting for query cache lock   | 0.000006 |
    | starting                       | 0.000008 |
    | Checking query cahce for query | 0.000051 |
    | Checking privileges on cached  | 0.000051 |
    | checking permissions           | 0.000006 |
    | sending cached result to clien | 0.000006 |
    | cleaning up                    | 0.000010 |
    +--------------------------------+----------+
    17 rows in set, 1 warning (0.00 sec)

可以看到同样的 `SQL`，第二次执行会去读缓存，如果缓存中有，就不会再执行之后的流程了

--------------------

#### 2.2.3 MySQL-8.0 中的 SQL 执行原理 ####

因为 `MySQL-8.0` 已经没有缓存了，所有不需要去设置 `query_cache_type`

这里我 `mike_inner` 库下有一个 `t_access_log` 的表，我对于该表进行两次查询操作

示例：

mysql> use mike_inner;
    Reading table information for completion of table and column names
    You can turn off this feature to get a quicker startup with -A
    
    Database changed
    
    mysql> SET profiling = 1;
    Query OK, 0 rows affected, 1 warning (0.00 sec)
    
    mysql> select * from t_access_log;
    +----+------------+-------------+-----------------+---------------------+-------+
    | id | login_name | access_path | access_ip       | create_time         | state |
    +----+------------+-------------+-----------------+---------------------+-------+
    |  1 | duojiala   | /auth/login | 192.168.110.193 | 2024-04-18 09:15:28 |     0 |
    |  2 | caodali    | /auth/login | 192.168.110.193 | 2024-04-18 09:16:27 |     1 |
    +----+------------+-------------+-----------------+---------------------+-------+
    2 rows in set (0.00 sec)
    
    mysql> select * from t_access_log;
    +----+------------+-------------+-----------------+---------------------+-------+
    | id | login_name | access_path | access_ip       | create_time         | state |
    +----+------------+-------------+-----------------+---------------------+-------+
    |  1 | duojiala   | /auth/login | 192.168.110.193 | 2024-04-18 09:15:28 |     0 |
    |  2 | caodali    | /auth/login | 192.168.110.193 | 2024-04-18 09:16:27 |     1 |
    +----+------------+-------------+-----------------+---------------------+-------+
    2 rows in set (0.00 sec)
    
    mysql> show profiles;
    +----------+------------+----------------------------+
    | Query_ID | Duration   | Query                      |
    +----------+------------+----------------------------+
    |        1 | 0.00030500 | select * from t_access_log |
    |        2 | 0.00027300 | select * from t_access_log |
    +----------+------------+----------------------------+
    2 rows in set, 1 warning (0.00 sec)
    
    mysql> show profile for query 1;
    +--------------------------------+----------+
    | Status                         | Duration |
    +--------------------------------+----------+
    | starting                       | 0.000064 |
    | Executing hook on transaction  | 0.000006 |
    | starting                       | 0.000008 |
    | checking permissions           | 0.000006 |
    | Opening tables                 | 0.000031 |
    | init                           | 0.000005 |
    | System lock                    | 0.000010 |
    | optimizing                     | 0.000004 |
    | statistics                     | 0.000014 |
    | preparing                      | 0.000015 |
    | executing                      | 0.000070 |
    | end                            | 0.000016 |
    | query end                      | 0.000004 |
    | waiting for handler commit     | 0.000008 |
    | closing tables                 | 0.000007 |
    | freeing items                  | 0.000020 |
    | cleaning up                    | 0.000020 |
    +--------------------------------+----------+
    17 rows in set, 1 warning (0.00 sec)
    
    mysql> show profile for query 2;
    +--------------------------------+----------+
    | Status                         | Duration |
    +--------------------------------+----------+
    | starting                       | 0.000066 |
    | Executing hook on transaction  | 0.000004 |
    | starting                       | 0.000008 |
    | checking permissions           | 0.000006 |
    | Opening tables                 | 0.000032 |
    | init                           | 0.000006 |
    | System lock                    | 0.000009 |
    | optimizing                     | 0.000005 |
    | statistics                     | 0.000013 |
    | preparing                      | 0.000015 |
    | executing                      | 0.000068 |
    | end                            | 0.000003 |
    | query end                      | 0.000003 |
    | waiting for handler commit     | 0.000007 |
    | closing tables                 | 0.000007 |
    | freeing items                  | 0.000012 |
    | cleaning up                    | 0.000010 |
    +--------------------------------+----------+
    17 rows in set, 1 warning (0.00 sec)

可以看出，不同于 `MySQL-5.7`，同样的 `SQL` 会走同样的流程，不存在缓存

--------------------

#### 2.2.4 SQL 语法顺序 ####

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

*  语法顺序：

SELECT DISTINCT
        <select_list>
    FROM
        <left_table> <join_type>
    JOIN <right_table> ON <join_condition>
    WHERE
        <where_condition>
    GROUP BY
        <group_by_list>
    HAVING
        <having_condition>
    ORDER BY
        <order_by_condition>
    LIMIT <limit_number>

*  解析顺序：

FROM <left_table>
    ON <join_condition>
    <join_type> JOIN <right_table>  -- 这一步和上一步，会循环执行
    WHERE <where_condition> -- 这一步会循环执行，多个条件从左往右
    GROUP BY <group_by_list>
    HAVING <having_condition>
    SELECT   -- 分组之后才执行SELECT
    DISTINCT <select_list>
    ORDER BY <order_by_condition>
    LIMIT <limit_number> -- 这一步是MySQL独有的语法，前面都是SQL92标准

--------------------

#### 2.2.5 Oracle 中的 SQL 执行流程 ####

`Oracle` 中采用了 `共享池` 来判断 `SQL` 语句是否存在缓存和执行计划，通过这一步骤可以知道应该采用硬解析还是软解析。

`SQL` 在 `Oracle` 中的执行过程：

![在这里插入图片描述][28d83e4d2eb649bc8bb65152ef2e6b08.png]

从上图可知，`SQL` 语句在 `Oracle` 中经历了以下几个步骤：

① 语法检查：检查 `SQL` 拼写是否正确，如果不正确，`Oracle` 会报语法错误

② 语义检查：检查 `SQL` 中的访问对象是否存在，比如我们在写 `SELECT` 语句的时候，列名写错了，系统就会提示错误。语法检查和语义检查的作用是保证 `SQL` 语句没有错误

③ 权限检查：看用户是否具备访问该数据的权限

④ 共享池检查：共享池（`Shared Pool`）是一块内存池，最主要的作用是缓存 `SQL` 语句和该语句的执行计划

> `Oracle` 通过检查共享池是否存在 `SQL` 语句的执行计划，来判断进行软解析还是硬解析。  
>   
>   
> 在共享池中，`Oracle` 首先对 `SQL` 语句进行 `Hash` 运算，然后根据 `Hash` 值在库缓存（`Library Cache`）中查找，如果存在 `SQL` 语句的执行计划，就直接拿来执行，直接进入执行器的环节，这就是 `软解析`。  
>   
>   
> 如果没有找到 `SQL` 语句和执行计划，`Oracle` 就需要创建解析树进行解析，生成执行计划，进入优化器这个步骤，这就是 `硬解析`。

⑤ 优化器：优化器中就是要进行硬解析，也就是决定怎么做，比如创建解析树，生成执行计划

> 共享池是 `Oracle` 中的术语，包括了库缓存、数据字典缓冲区等。`库缓存` 主要缓存 `SQL` 语句和执行计划，而 `数据字典缓冲区` 存储的是 `Oracle` 中的对象定义，比如表、视图、索引等对象，当对 `SQL` 语句进行解析的时候，如果需要相关的数据，会从数据字典缓冲区中提取  
>   
>   
> `库缓存` 这一步骤决定了 `SQL` 语句是否需要进行硬解析，为了提示 `SQL` 的执行效率，我们应该尽量避免硬解析，因为在 `SQL` 的执行过程中，创建解析树、生成执行计划是很消耗资源的  
>   
>   
> 因此，可以通过使用绑定变量来减少硬解析，减少 `Oracle` 的解析工作量，但是这种方式也有缺点，使用动态 `SQL` 的方式，因为参数不同，会导致 `SQL` 的执行效率不同，同时 `SQL` 优化也比较困难

`Oracle` 和 `MySQL` 在进行 `SQL` 的查询上面有软件实现层面的差异，`Oracle` 提出了共享池的概念，通过共享池来判断是进行软解析还是硬解析。

--------------------

## 三、数据库缓冲池 ##

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

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

--------------------

### 3.1 缓冲池 & 查询缓存 ###

*  缓冲池

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

![在这里插入图片描述][7bc648d6569444b1ab04818ca5adb3e7.png]

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

**缓存池的重要性：**

对于使用 `InnoDB` 作为存储引擎的表来说，不管是用于存储用户数据的索引（包含聚簇索引和二级索引），还是各种系统数据，都是以 `页` 的形式存放在 `表空间` 中的，而所谓的表空间只不过是 `InnoDB` 对文件系统上一个或几个实际文件的抽象，也就是说我们的数据说到底还是存储在磁盘上的。但是磁盘的速度比较满，和 `CPU` 的高性能是匹配的，但是缓冲池可以消除 `CPU` 和磁盘之间的鸿沟。所以 `InnoDB` 存储引擎在处理客户端的请求时，当需要访问某个页的数据时，就会把 `完整的数据全部加载到内存` 中，存中后就可以进行读写访问了，在进行读写访问之后并不着急把该页对应的内存空间释放掉，而是将其 `缓存` 起来，这样将来有请求再次访问该页面时，就可以 `省去磁盘 I/O` 的开销了。

**缓存的原则：**

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

首先，位置决定效率，提供缓冲池就是为了在内存中可以直接访问数据，其次，频次决定优先级顺序，因为缓冲池的大小有限，比如磁盘有 `200G`，但内存只有 `16G`，缓冲池大小只有 `1G`，就无法将所有数据都加载到缓冲池里，这时就涉及到优先级顺序，会优先使用频次高的热数据进行加载。

**缓冲池的预读特性：**

缓冲池的另一个特性就是 `预读`。缓冲池的作用就是提升 `I/O` 效率，而我们进行读取数据的时候存在一个局部性原理，也就是说我们使用一些数据，`大概率还会使用它周围的一些数据`，因此采用预读的机制提前记载，可以减少未来可能的磁盘 `I/O` 操作。

*  查询缓冲

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

缓冲池服务于数据库整体的 `I/O` 操作，它们的共同点都是通过缓存的机制来提升效率。

--------------------

### 3.2 缓冲池如何读取数据 ###

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

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

![在这里插入图片描述][e272ae39d5a747b2bb90ca5287488d58.png]

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

实际上，当我们对数据库中的记录进行修改的时候，首先会修改缓冲池中页里面的记录信息，然后数据库会 `以一定的频率刷新` 到磁盘上。注意并不是每次发生更新操作都会立刻进行磁盘回写。缓冲池采用一种叫做 `checkpoint 的机制` 将数据回写到磁盘上，这样做的好处就是提升了数据库的整体性能。

比如，当 `缓冲池不够用` 时，需要释放掉一些不常用的页，此时就可以强行采用 `checkpoint` 的方式，将不常用的脏页回写到磁盘上，然后再从缓冲池中将这些页释放掉。这里脏页（`dirty page`）指的是缓冲池中被修改过的页，与磁盘上的数据页不一致。

--------------------

### 3.3 查看设置缓冲池的大小 ###

如果你使用的是 `MySQL MyISAM` 存储引擎，它只缓存索引，不缓存数据，对应的健缓存参数为 `key_buffer_size`，可以用它进行查看。

如果你使用的是 `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;

或者修改配置文件 `my.cnf`，添加配置如下：

[mysqld]
    innodb_buffer_pool_size = 268435456

改完需要重启数据库才能生效

--------------------

### 3.4 多个 Buffer Pool 实例 ###

`Buffer Pool` 本质上 `InnoDB` 向操作系统申请的一块 `连续的内存空间`，在多线程环境下，访问 `Buffer Pool` 中的数据都需要 `加锁` 处理。在 `Buffer Pool` 特别大而且多线程并发访问特别高的情况下，单一的 `Buffer Pool` 可能会影响请求的处理速度。所以在 `Buffer Pool` 特别大的时候，我们可以把它们 `拆分成若干个小的 Buffer Pool`，每个 `Buffer Pool` 都称为一个 `实例`，它们都是独立的，独立的去申请内存空间，独立的管理各种链表。所以在多线程并发访问时并不会相互影响，从而提高并发处理能力。

我们可以在服务器启动的时候通过设置 innodb\_buffer\_pool\_instances 的值来修改 Buffer Pool 实例的个数，比如这样：

[mysqld]
    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` 实例占用的大小。

不过也不是说 `Buffer Pool` 实例创建得越多越好，分别 管理各个 `Buffer Pool` 也是需要性能开销 的，`InnoDB` 规定：当 `innodb_buffer_pool_size` 的值小于 `IG` 的时候设置多个实例是无效的，`InnoDB` 会默认把 `innodb_buffer_pool_instances` 的值修改为 1，而我们鼓励在 `Buffer Pool` 大于或等于 `IG` 的时候设置多个 `Buffer Pool` 实例。

--------------------

### 3.5 引申问题 ###

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

**黑河下的更新数据流程**

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

![在这里插入图片描述][e4ce747d600844c2af9d7e34ea01ba42.png]

这个过程看似没有啥问题，实则是有问题的。假设我们修改 `Buffer Pool` 中的数据成功，但是还没来得及将数据刷入磁盘 `MySQL` 就挂了怎么办？按照上图的逻辑，此时更新之后的数据只存在于 `Buffer Pool` 中，如果此时 `MySQL` 宕机了，这部分数据将会永久地丢失。

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

--------------------

上篇：[第四章、配置文件与系统变量][Link 1]  
下篇：[第六章、存储引擎][Link 2]

[Link 1]: https://blog.csdn.net/xhmico/article/details/138246022
[Link 2]: https://blog.csdn.net/xhmico/article/details/138370026
[bilibili-_-MySQL]: https://www.bilibili.com/video/BV1iq4y1u7vj?p=109
[07908bf0a2714820a44c24abe3abbcfa.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/06/cfde50a79f6a433ba73314f6427cd8a1.png
[bb9b851a0b605c22d74be72b6a01b90d.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/06/52c79b101fda4c7090cb1a52ea78cbf0.png
[134608d365c447508142bf975a8999f4.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/06/fda1b7cfac764aa8ad2d4142150495a8.png
[e502db57fadc4f4ca033cb0cf50d716f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/06/68a90b40719844b1ba1466dcba4b5f52.png
[cf2fc378b7cb4075bea466c50e01e4a2.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/06/73300c58d7bf4e478e0cc40814f01bf3.png
[5c43a6a3461142feaa19ac3116b6f6ae.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/06/15ce5b5713424f34b3d4067d55438f14.png
[286687da8c594eebb8b519b53db7aedd.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/06/720bf468edcc4b7d989bcefef936eaab.png
[bdf8ede4c59749c48e5b2477e79ce55c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/06/1229afdf583a4258addd91cfd356d9f2.png
[969f09bc4d4441d994215e382a55ccb5.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/06/42e4665bff3f4e78a1d9a2e500650075.png
[9ad117757ed54fd6bf0f3615d9b591dd.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/06/b5dc9c53e6ad417795b4110cf97ad514.png
[88f713deb0ad4d88981361a67ca68500.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/06/f76d74ce60504bf8aa5768a773a3f937.png
[8189ebb3c94b4982ac2da1c6b1e6b2a8.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/06/2a7be649fa4e4e69bb4d4bad133da24d.png
[8014b3eb4b4b48c38534b0155e7843c3.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/06/6c4f4f40aaa74e53b7ae89e21ab5caaa.png
[6a18fcd3e2124f6591de625f4fb9c5c0.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/06/6ed2fcb48489450baa4100093eab815c.png
[28d83e4d2eb649bc8bb65152ef2e6b08.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/06/c6847e6db45d4f14b0f67fa15f0adadd.png
[7bc648d6569444b1ab04818ca5adb3e7.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/06/43a9f77228904e7091e13d20fd123058.png
[e272ae39d5a747b2bb90ca5287488d58.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/06/d0a6ab185e3948efbc586920409a20ff.png
[e4ce747d600844c2af9d7e34ea01ba42.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/06/85e0d9806fae41d7b8f34c296e73941b.png