MySQL中的redo log详解

柔情只为你懂 2022-12-24 10:48 144阅读 0赞

redo log重做日志，顾名思义，其实它的作用是在MySQL宕机之后，用来恢复数据的一种log文件，那么为什么需要redo log呢？

之前一篇文章我们讲过了[Buffer Pool][]，知道了缓存页的机制，数据的增删改查都是先将磁盘中数据页的数据加载到Buffer Pool中的缓存页，然后再对缓存页中的数据进行操作，如果数据经过了增删改的操作，那么这些数据就是脏数据了，因为缓存页中的数据和磁盘中的数据不一致，Buffer Pool是会不断的将脏数据刷入磁盘的，但是这个速度太慢了

首先一个缓存页就有16K，如果将一个完整的缓存页刷入磁盘，那么必然比较耗费时间，如果一个缓存页中只修改了少量的数据，那么也不可能将一个完整的缓存页刷入磁盘；还有一个原因就是缓存页刷磁盘这个操作是随机写，性能很差

通过上面的描述，我们就可以发现依靠缓存页刷入磁盘来保证MySQL的稳定性不靠谱，一旦MySQL宕机，那么缓存页中的数据就丢了。那如果我们提交了事务，但是缓存页的数据还没来得及刷入磁盘，那不是就前功尽弃了，所以就需要我们的redo log日志了

当更新了Buffer Pool之后，就必须写一条redo log，一旦MySQL宕机，重启之后MySQL就会根据redo log恢复当时更新的缓存页，那么redo log是如何解决我们上面缓存页遇到的问题的呢？

首先redo log非常小，可能也就几十个字节，里面包含了表空间、数据页号、磁盘文件偏移量、更新值、日志类型这些信息，大概格式如下：  
**对表空间XX中的数据页XX中的偏移量为XXXX的地方更新了数据XXX**

其次redo log是顺序写，所以每次都是追加到磁盘文件末尾，速度非常快，这两点就保证了写入redo log非常快，从而加强了MySQL的并发能力

redo log格式中的其他信息都比较好理解，那么日志类型是指的什么呢？  
其实里面的偏移量具体到了偏移了几个字节的值，根据这个分为了几种不同的类型，如果是修改了一个字节的话，那类型就是MLOG\_1BYTE，两个字节就是MLOG\_2BYTE，依次类推还有4和8个字节。还有一种特殊情况，就是一口气修改了一大堆的值，此时就是MLOG\_WRITE\_STRING，如果是这种类型的话，就需要多一个指定具体多少个字节的字段

现在我们已经知道了redo log很小，也就几十个字节左右，那么redo log肯定不是一条条写入磁盘文件的，肯定有一个批量处理的逻辑，这就是redo log block，一个redo log block包含了多个redo log，大小为512字节，分为了三部分，分别是header块头（12字节），body块体（496字节）和trailer块尾（4字节）

其中块头又分成了四部分，分别解释一下：

1.  4个字节的block no，块的唯一编号
2.  2个字节的data length，就是block里写入了多少字节的数据
3.  2个字节的first record group。这个是说每个事务都会有多个redo log，是一个redo log group，即一组redo log。那么在这个block里的第一组redo log的偏移量，就是这两个字节存储的
4.  4个字节的checkpoint on

每个redo log都是顺序写入到redo log block中，一个redo log block最多存放496字节的redo log，当一个redo log block被写满之后，再将这个redo log block写入redo log日志文件中，在这里，其实还有一个概念，就是redo log buffer，顾名思义，这也是一个缓存，类似于Buffer Pool，这里面缓存的是多个空的redo log block，只有满足了一定的条件，redo log buffer才会真正的将我们的redo log刷入磁盘中

redo log block真正刷入磁盘的时机大概有4个：

1.  redo log buffer的日志占了总容量的一半，一个redo log buffer默认是16M，一半的话也就是8M，就刷盘
2.  当一个事务提交的时候，redo log所在的redo log block就会刷盘
3.  后台线程每隔一秒将redo log buffer里面的redo log block刷入磁盘
4.  MySQL关闭的时候，redo log block刷盘

当redo log刷入到磁盘中，就能保证MySQL里面的数据万无一失了  
![redo log][]

[Buffer Pool]: https://blog.csdn.net/LO_YUN/article/details/109630780
[redo log]: /images/20221120/14c94941fbfd4aad9c00061786bbc09f.png