从一条更新SQL的执行过程窥探InnoDB之REDOLOG-京东云开发者社区

### 1 前言

数据库为了取得更好的读写性能，InnoDB会将数据缓存在内存中（InnoDB Buffer Pool），对磁盘数据的修改也会落后于内存，这时如果进程或机器崩溃，会导致内存数据丢失，为了保证数据库本身的一致性和持久性，InnoDB维护了REDO LOG。修改Page之前需要先将修改的内容记录到REDO中，并保证REDO LOG早于对应的Page落盘，也就是常说的WAL，Write Ahead Log。当故障发生导致内存数据丢失后，InnoDB会在重启时，通过重放REDO，将Page恢复到崩溃前的状态。

### 2 MYSQL更新语句的执行过程

#### 2.1 MYSQL的体系结构

大体来说，MySQL 可以分为 客户端、Server层和存储引擎层三大部分，如图所示。

Server 层包括连接器、查询缓存、分析器、优化器、执行器等，涵盖 MySQL 的大多数核心服务功能，以及所有的内置函数（如日期、时间、数学和加密函数等），所有跨存储引擎的功能都在这一层实现，比如存储过程、触发器、视图等。

存储引擎层负责数据的存储和提取。其架构模式是插件式的，支持 InnoDB、MyISAM、Memory 等多个存储引擎。现在最常用的存储引擎是 InnoDB，它从 MySQL 5.5.5 版本开始成为了默认存储引擎。

![](//img1.jcloudcs.com/developer.jdcloud.com/deefb6a3-a236-4f8f-aecc-20abd906082d20220624112020.png)

#### 2.2 更新SQL的执行

当我们执行一条更新SQL时是如何执行的呢，下面执行一条简单的SQL更新语句(默认存储引擎InnoDB)

```sql
update T set c=c+1 where ID=2;
```

**第一步：连接器**
先通过连接器连接到这个数据库上。连接器负责跟客户端建立连接、校验用户名密码的正确性,同时获取该用户的权限放到缓存中、维持和管理连接

**第二步：缓存**
连接建立完成后，如果执行的是SELECT查询 语句会查询缓存中是否存在该SQL的结果集，如果存在结果则再校验用户表和数据的权限最终将查询到的结果返回。如果是UPDATE，DELETE等更新操作，那么跟这个表有关的查询缓存会置为失效，所以这条语句就会把表 T 上所有缓存结果都清空。

**第三步：分析器**
如果没有命中查询缓存，就要开始真正执行语句了。首先，MySQL 需要知道你要做什么，因此需要对 SQL 语句做解析。
分析器先会做“词法分析”。你输入的是由多个字符串和空格组成的一条 SQL 语句，MySQL 需要识别出里面的字符串分别是什么，代表什么。例如该语句中c列在表T中是否存在等。
做完了这些识别以后，就要做“语法分析”。根据词法分析的结果，语法分析器会根据语法规则，判断你输入的这个 SQL 语句是否满足 MySQL 语法。该SQL语句中的update、where 等是否符合SQL语法

**第四步：优化器**
经过了分析器，MySQL 就知道你要做什么了。在开始执行之前，还要先经过优化器的处理。优化器是在表里面有多个索引的时候，决定使用哪个索引；或者在一个语句有多表关联（join）的时候，决定各个表的连接顺序；优化器决定要使用 ID 这个索引。指定索引也就指定了后面的执行器需要调用存储引擎的哪个接口进行执行。

**第五步：执行器**
MySQL 通过分析器知道了你要做什么，通过优化器知道了该怎么做，于是就进入了执行器阶段，开始执行语句。开始执行的时候，要先判断一下你对这个表 T 有没有执行查询的权限，如果没有，就会返回没有权限的错误。执行器负责具体执行，找到这一行，然后更新。

![](//img1.jcloudcs.com/developer.jdcloud.com/abe7a383-51d6-4a4d-bb9d-f084659d135020220624112850.png)

### 2.3 InnoDB存储引擎引入REDOLOG

Mysql本身有自己的日志记录binlog(归档日志:分为row，statement两种模式)，但是只依靠binlog是没有crash-safe能力的，所以在存储引擎层InnoDB使用另外一套日志系统redolog来实现crash-safe能力。同时为了取得更好的读写性能，InnoDB会将数据缓存在内存中（InnoDB Buffer Pool），对磁盘数据的修改也会落后于内存，这时如果进程或机器崩溃，会导致内存数据丢失，从而保证数据库本身的一致性和持久性。修改Page之前需要先将修改的内容记录到REDO中，并保证REDO LOG早于对应的Page落盘，也就是常说的WAL，Write Ahead Log。当故障发生导致内存数据丢失后，InnoDB会在重启时，通过重放REDO，将Page恢复到崩溃前的状态。

那么我们需要什么样的REDO呢？

首先，REDO的维护增加了一份写盘数据，同时为了保证数据正确，事务只有在他的REDO全部落盘才能返回用户成功，REDO的写盘时间会直接影响系统吞吐，显而易见，REDO的数据量要尽量少。其次，系统崩溃总是发生在始料未及的时候，当重启重放REDO时，系统并不知道哪些REDO对应的Page已经落盘，因此REDO的重放必须可重入，即REDO操作要保证幂等。最后，为了便于通过并发重放的方式加快重启恢复速度，REDO应该是基于Page的，即一个REDO只涉及一个Page的修改。
数据量小是Logical Logging的优点，而幂等以及基于Page正是Physical Logging的优点。InnoDB采取了一种称为Physiological Logging的方式，来兼得二者的优势。所谓Physiological Logging，就是以Page为单位，但在Page内以逻辑的方式记录。举个例子，一种作用于Page类型的REDOLOG中记录了对Page中一个Record的修改，方法如下：

```
（Page ID，Record Offset，(Filed 1, Value 1) … (Filed i, Value i) … )
```

其中，PageID指定要操作的Page页，Record Offset记录了Record在Page内的偏移位置，后面的Field数组，记录了需要修改的Field以及修改后的Value。

#### 2.4 REDOLOG的记录内容

![](//img1.jcloudcs.com/developer.jdcloud.com/776944b8-87f3-452b-ae46-41f12bd8ac7520220624112947.png)

其中Type就是记录的作用对象(根据REDO记录不同的作用对象，可划分为三个大类：作用于Page，作用于Space以及提供额外信息的Logic类型)，Space ID和Page Number唯一标识一个Page页，这三项是所有REDO记录都需要有的头信息。

后面的是MLOG_REC_UPDATE_IN_PLACE类型(作用于Page)独有的，其中Record Offset用给出要修改的记录在Page中的位置偏移，Update Field Count说明记录里有几个Field要修改，紧接着对每个Field给出了Field编号(Field Number)，数据长度（Field Data Length）以及数据（Filed Data）

### 3 总结

通过对一个更新SQl语句执行过程的跟踪，了解熟悉Mysql的执行过程，了解REDOLOG的数据的内容格式，从根本上理解REDOLOG的设计的思路和原理，为以后的应用系统的开发和设计提供思想上的借鉴和实践。

------------
###### 自猿其说Tech-JDL京东物流技术与数据智能部
###### 作者：王义杰