InnoDB学习（四）之RedoLog和UndoLog

BinLog是MySQL Server层的日志，所有的MySQL存储引擎都支持BinLog。BinLog可以支持主从复制和数据恢复，但是对事务的ACID特性支持比较差。InnoDB存储引擎引入RedoLog和UndoLog事务日志，用于提升事务场景下的数据库性能。本文会对RedoLog和UndoLog进行介绍。

RedoLog和UndoLog

ChangeBuffer和WAL

我们以一条SQL更新语句来介绍RedoLog的作用，首先在数据库中创建user_info表，该表包含主键列id和姓名列，并向数据库中插入一列测试数据：

create table user_info
(
    id int primary key,
    name  varchar(255)
);

insert into user_info(id,name) value (1,'ls');

查询语句的执行流程

如果我们需要查询id=1的用户的信息，我们可以通过以下SQL语句进行查询：

select  * from user_info where id = 1;

在这一条简单的查询语句之后，MySQL做了哪些工作呢？如下所示，MySQL执行SQL查询语句的流程包含以下步骤：

1. 连接器：客户端和MySQL服务端建立连接，用户名密码等信息校验；
2. 查询缓存：如果SQL语句是查询语句，则查看查询语句是否命中缓存；
3. 分析器：对SQL语句的词法和语法进行分析，判断SQL语句的类型和对应的表等信息；
4. 优化器：对SQL语句进行优化，选择合适的索引；
5. 执行器：在对应的MySQL引擎上执行SQL查询语句，并返回查询结果；

更新语句的执行流程

如果我们不需要查询用户信息，而是要更新id=1的记录中的用户名为zs，则可以通过以下SQL语句进行更新：

update user_info set name="zs" where id=1;

和上文中的查询语句类似，MySQL一样会先通过连接器建立数据库连接，然后通过分析器、优化器和执行器查找到需要更新的数据所在的行，然后更新数据。

和查询流程不一样的是，更新流程还涉及ChangeBuffer和两个重要的日志模块：BinLog和RedoLog。其中BinLog和ChangeBuffer的作用已经在前文中介绍过，BinLog用于主从复制和数据恢复，ChangeBuffer用于缓存对数据库中数据的操作，RedoLog则是本文介绍的主角了。

ChangeBuffer技术

对于上文中的更新语句，如果没有RedoLog，那么InnoDB引擎会按照索引查找到id=1的用户记录，把记录加载到内存中，然后修改内存中的数据事务提交后再写回磁盘。如果数据库数据更新的频率非常低，那么这样更新方式数据库也可以接受，但是在更新非常频繁的情况下，大量的离散IO会成为数据库的瓶颈，影响数据库的性能。

在更新频繁的场景下，如何降低磁盘的IO并保证事务呢？这就涉及到我们前边文章中介绍过的ChangeBuffer技术了，在满足ChangeBuffer缓存操作的条件下，InnoDB并不会立即把数据的变更操作写入磁盘，而是将这些对数据页的操作缓存到ChangeBuffer中，数据库找合适的机会再将操作Merge到数据库中。

通过ChangeBuffer技术，我们可以把对数据库的多次离散访问合并为一次数据库访问，并且用户的更新线程中不需要实际访问磁盘，大大提升了数据库性能。

WAL技术

不过不知道大家有没有注意到，ChangeBuffer有一个很大的问题：如果InnoDB实例在运行期间掉电，ChangeBuffer中的缓存会丢失，从而造成数据库数据的不一致，影响数据库事务的原子性和一致性。

数据库中保证事务原子性和一致性通用的方案是采用WAL（Write-ahead logging，预写式日志）技术，在使用WAL的系统中，所有的修改都先被写入到日志中，然后再被应用到系统状态中，日志通常包含redo和undo两部分信息。

• RedoLog称为重做日志，每当有操作时，在数据变更之前将操作写入RedoLog，这样当发生掉电之类的情况时系统可以在重启后继续操作；
• UndoLog称为撤销日志，当一些变更执行到一半无法完成时，可以根据撤销日志恢复到变更之间的状态；

MySQL的InnoDB引擎中就使用了WAL技术，所以InnoDB存储引擎包含了RedoLog和UndoLog两部分日志。

如何确保已经提交的事务不会丢失？解决这个问题比较简单，InnoDB有一个Log-Force-at-Commit机制，在事务提交的时候，和这个事务相关的RedoLog数据，包括Commit记录，都必须从LogBuffer中写入RedoLog文件，此时事务提交成功的信号才能发送给用户进程。通过这个机制，可以确保哪怕这个已经提交的事务中的部分ChangeBuffer还没有被写入数据文件，就发生了实例故障，在做实例恢复的时候，也可以通过RedoLog的信息，将不一致的数据前滚。

RedoLog和BinLog比较

RedoLog和BinLog不同。虽然BinLog中也记录了InnoDB表的很多操作，也能实现重做的功能，但是它们之间有很大区别。

1. BinLog是在存储引擎的上层产生的，不管是什么存储引擎，对数据库进行了修改都会产生二进制日志。而RedoLog是Innodb引擎层产生的，只记录该存储引擎中表的修改；
2. BinLog记录数据变更的逻辑性的语句，如某一行数据的的变更情况或此次变更的SQL语句。而RedoLog是在物理格式上的日志，它记录的是数据库中每个页的修改；
3. BinLog只在每次事务提交的时候一次性写入缓存中的日志"文件"(对于非事务表的操作，则是每次执行语句成功后就直接写入)。而RedoLog在数据准备修改前写入缓存中的RedoLog中，然后才对缓存中的数据执行修改操作；而且保证在发出事务提交指令时，先向缓存中的RedoLog写入磁盘日志，写入完成后才执行提交动作；
4. BinLog只在提交的时候一次性写入，所以BinLog记录方式和提交顺序有关，且一次提交对应一次记录。而RedoLog中是记录的物理页的修改，RedoLog文件中同一个事务可能多次记录，最后一个提交的事务记录会覆盖所有未提交的事务记录。例如事务T1，可能在RedoLog中记录了T1-1,T1-2,T1-3，T1共4个操作，其中T1表示最后提交时的日志记录，所以对应的数据页最终状态是T1对应的操作结果。而且RedoLog是并发写入的，不同事务之间的不同版本的记录会穿插写入到RedoLog文件中，例如可能RedoLog的记录方式如下： T1-1,T1-2,T2-1,T2-2,T2,T1-3,T1* 。

事务日志记录的是物理页的情况，它具有幂等性，因此记录日志的方式极其简练。幂等性的意思是多次操作前后状态是一样的，例如新插入一行后又删除该行，前后状态没有变化。而二进制日志记录的是所有影响数据的操作，记录的内容较多。例如插入一行记录一次，删除该行又记录一次。

RedoLog

RedoLog包括两部分：一是内存中的日志缓冲(RedoLog Buffer)，该部分日志是易失性的；二是磁盘上的重做日志文件(RedoLog File)，该部分日志是持久的。

在概念上，Innodb通过force-log-at-commit机制实现事务的持久性，即在事务提交的时候，必须先将该事务的所有事务日志写入到磁盘上的RedoLog File和UndoLog File中进行持久化。

为了确保每次日志都能写入到事务日志文件中，在每次将RedoLog Buffer中的日志写入日志文件的过程中都会调用一次操作系统的fsync操作(即fsync()系统调用)。因为Maria