【数据库】MySQL中的redolog、undolog、binlog

【数据库】MySQL中的redolog、undolog、binlog 2022-05-12 251

前言

binlog是mysql服务层的东西，主要用于主从复制，而redolog和undolog是innodb引擎层的东西。

一、redoLog

MySQL的数据最终是存放在磁盘中的，但是如果操作都是通过读写磁盘来进行的话，磁盘的I/O效率太低。所以InnoDB（又是这个NB引擎）为MySQL提供了缓冲池（Buffer Pool）,Buffer Pool中包含了磁盘中部分数据页的映射。

从数据库读数据时，先从Buffer Pool中读取数据，如果Buffer Pool中没有，则从磁盘读取后放入到Buffer Pool中。当向数据库写入数据时，会先写入到Buffer Pool中，Buffer Pool中更新的数据会定期刷新到磁盘中（此过程称为刷脏）。

虽然Buffer Pool为MySQL的读写提高了效率，但是断电即失，持久性保证不了。为了解决这个问题，redo log就出现了。

在对Buffer Pool中的数据进行修改的时候通过redo log记录这次操作，当事务提交时会对redo log进行刷盘，同步在磁盘中，所以当MySQL出现宕机时，可以从磁盘中读取redo log进行数据的恢复，从而保证了事务的持久性。

另外注意，redo log 采用的预写的方式记录日志，即先记录日志，再更新Buffer Pool，这样就强行的保证了，数据只要保存在了redo log中就一定会存储到磁盘中了。

redo log 也是写磁盘，刷脏也是写磁盘，为啥要先记录redo log而不是直接刷脏？

主要原因就是redo log比刷脏快很多。

第一点是，redo log是追加操作日志，是顺序IO；而刷脏是随机IO，因为每次更新的数据不一定是挨着的，也就是随机的。
第二点是，刷脏是以数据页（Page）为单位的（即每次最少从磁盘中读取一页数据到内存，或者最少刷一页数据到磁盘），MySQL默认页大小是16KB，对一个页上的修改，都要整个页都刷到磁盘中；而redo log只包含真正的需要写入磁盘的操作日志。

二、undoLog

它主要用于MVCC中记录回滚。如果事务出错了，恢复原来的数据就靠它了。

undoLog 也就是我们常说的回滚日志文件主要用于事务中执行失败，进行回滚，以及MVCC中对于数据历史版本的查看。 undo log由引擎层的InnoDB引擎实现,是逻辑日志,记录数据修改被修改前的值,比如"把id=‘B’ 修改为id = ‘B2’ ，那么undo日志就会用来存放id =B’的记录”。当一条数据需要更新前,会先把修改前的记录存储在undolog中,如果这个修改出现异常,则会使用undo日志来实现回滚操作,保证事务的原子性和一致性。当事务提交之后，undo log并不能立马被删除,而是会被放到待清理链表中,待判断没有事物用到该版本的信息时才可以清理相应undolog。它保存了事务发生之前的数据的一个版本，用于回滚，同时可以提供多版本并发控制下的读（MVCC），也即非锁定读。