面试必问 | 聊聊MySQL三大核心日志的实现原理？（一）

大家好，我是冰河~~

MySQL几乎成为互联网行业使用的最多的开源关系型数据库，正因如此，MySQL也成为各大互联网公司面试中必问的数据库，尤其是MySQL中的事务实现机制和三大核心日志的实现原理。

有关MySQL的事务实现机制小伙伴们可以参见冰河出版的《深入理解分布式事务：原理与实战》一书。

今天，我们就重点聊聊MySQL三大核心日志的实现原理。

文章已收录到：

https://github.com/sunshinelyz/technology-binghe

https://gitee.com/binghe001/technology-binghe

MySQL日志

说起MySQL的日志，有三种类型的日志对于MySQL来说是至关重要的，这三种日志分别为：Binlog、Undo Log 和 Redo Log。

由于Binlog和UndoLog有类似的地方，所以，我们按照如下顺序依次介绍MySQL中的三大日志原理：Undo Log——> Redo Log ——> Binlog。

Undo Log日志

什么是Undo Log
顾名思义，Undo Log的字面意思就是撤销操作的日志，指的是使MySQL中的数据回到某个状态。

在MySQL数据库中，事务开始之前，MySQL会将待修改的记录保存到Undo Log中，如果数据库崩溃或者事务需要回滚时，MySQL可以通过利用Undo Log日志，将数据库中的数据回滚到之前的状态。

MySQL新增、修改和删除数据时，在事务开始前，就会将信息写入Undo Log中。事务提交时，并不会立刻删除Undo Log， InnoDB存储引擎会将事务对应的Undo Log放入待删除列表中，之后会通过后台的purge thread对待删除的列表进行删除处理。

这里，值得注意的是：Undo Log是一种 逻辑日志， 记录的是一个变化过程。比如，MySQL执行一个delete操作，Undo Log就会记录一个insert操作；MySQL执行一个insert操作，Undo Log就会记录一个delete操作；MySQL执行一个update操作，Undo Log就会记录一个相反的update操作。

Undo Log以段的方式来管理和记录日志信息，在InnoDB存储引擎的数据文件中，包含了一种叫做rollback segment的回滚段，其内部包含了1024个undo log senment。

Undo Log作用
Undo Log对于MySQL实现事务来说，起着至关重要的作用，它实现了事务的原子性和多版本并发控制，也就是我们经常说的MVCC。

• 实现事务的原子性
  Undo Log能够实现MySQL事务的原子性，在事务的处理过程中，如果MySQL出现了错误或者用户手动执行了事务的回滚操作（执行了rollback操作），MySQL可以利用Undo Log日志将数据库中的数据恢复到之前的状态。
• 实现MVCC机制
  Undo Log在MySQL的InnoDB存储引擎中实现了多版本并发控制（MVCC）机制。

为了方便大家理解，这里，我将MVCC的具体实现进行了简化，后续会单独写一篇MVCC的具体实现过程的文章。

事务未提交前，Undo Log保存了未提交之前的版本数据，Undo Log中的数据可以作为旧版本数据的副本或者快照以便其他并发事务进行读取操作。

 
事务A手动开启事务后，对goods数据表中id为1的数据进行更新操作，首先会把更新命中的数据写入到Undo Buffer中。

在事务A未提交之前，此时，事务B手动开启事务，对goods数据表中的id为1的数据进行查询操作，此时的事务B会读取Undo Log中的数据并返回给客户端，这就是MySQL中的MVCC机制。

可以在MySQL中通过下面的命令来查看控制Undo Log日志的参数。

show variables like '%innodb_undo%';

Redo Log日志

说了MySQL中的Undo Log，我们再来看看MySQL中的Redo Log日志。

什么是Redo Log
顾名思义Redo Log的字面意思就是重做日志，指的是在数据库出现意外情况时能够对重新执行某种操作。在MySQL中，事务中修改的任何数据，都会将最新的数据写入Redo Log中进行备份。

在MySQL中，随着事务操作的执行，就会产生Redo Log日志，在事务提交时会产生Redo Log并将其写入Redo Buffer，Redo Buffer也并不是随着事务的提交就会被立刻写入到磁盘中，而是等事务操作的脏页写入到磁盘之后，Redo Log的使命也就完成了，此时，Redo Log日志占用的空间可以重新利用，会被后续产生的Redo Log日志覆盖。

Redo Log的原理
Redo Log 能够实现事务的持久性，防止在发生故障的时间点，有脏页未写入表的 ibd 文件中，在重启 MySQL 服务的时候，根据 Redo Log 进行重做，从而将未提交的事务进行持久化。这个过程可以简化为下图所示。

 
Redo Log的写机制
Redo Log文件的内容是以顺序循环的方式写入文件的，写满时就会回到第一个文件，进行覆盖写。

• Write Pos 是当前记录的位置，一边写一边后移，写到最后一个文件末尾后就回到 0 号文件开头；
• CheckPoint是当前要擦除的位置，也是往后推移并且循环的，擦除记录前要把记录更新到数 据文件；
  Write Pos 和 CheckPoint之间还空着的部分，可以用来记录新的操作。如果 Write Pos 追上 CheckPoint，表示已经写满，此时就需要向后移动CheckPoint来擦除数据。

每个InnoDB存储引擎至少有1个重做日志文件组（group），每个文件组至少有2个重做日志文件，默认为ib_logfile0和ib_logfile1 。

可以在MySQL中通过如下命令来查看控制Redo Log的参数。

show variables like '%innodb_log%';

Redo Log写入机制
在Redo Log日志信息从Redo Buffer持久化到Redo Log时，具体的持久化策略可以通过innodb_flush_log_at_trx_commit 参数进行设置，具体策略如下所示。

• 0：每秒提交 Redo buffer ->OS cache -> flush cache to disk，可能丢失一秒内的事务数据。由后台Master线程每隔 1秒执行一次操作。
• 1（默认值）：每次事务提交执行 Redo Buffer -> OS cache -> flush cache to disk，这种方式最安全，性能最差。
• 2：每次事务提交执行 Redo Buffer -> OS cache，然后由后台Master线程再每隔1秒执行OS cache -> flush cache to disk 的操作。
  一般建议选择取值2，因为 MySQL 挂了数据没有损失，整个服务器挂了才会损失1秒的事务提交数据。

文章转自公众号：冰河技术