MySQL日志系统:redo log、bin log、undo log的基础知识

1 redo log

1.1 为什么需要redo log

我们都知道，事务的四大特性里面有一个是 持久性 ，具体来说就是只要事务提交成功，那么对数据库做的修改就被永久保存下来了，不可能因为任何原因再回到原来的状态 。

那么 mysql是如何保证一致性的呢？

最简单的做法是在每次事务提交的时候，将该事务涉及修改的数据页全部刷新到磁盘中。但是这么做会有严重的性能问题，主要体现在两个方面：

1. Innodb 是以页为单位进行磁盘交互的，而一个事务很可能只修改一个数据页里面的几个字节，如果将完整的数据页刷到磁盘的话，会很浪费资源
2. 一个事务可能涉及修改多个数据页，并且这些数据页在物理上并不连续，使用随机IO写入性能太差

因此 mysql 设计了 redo log ， 具体来说就是只记录事务对数据页做了哪些修改，这样就能完美地解决性能问题了(相对而言文件更小并且是顺序IO)。

1.2 什么时候产生

事务开始之后就产生redo log，redo log的落盘并不是随着事务的提交才写入的，而是在事务的执行过程中，便开始写入redo log文件中。

1.3 什么时候释放

当对应事务的脏页写入到磁盘之后，redo log的使命也就完成了，重做日志占用的空间就可以重用（被覆盖）。

1.4 redo log 作用

确保事务的持久性。防止在发生故障的时间点，尚有脏页未写入磁盘，在重启mysql服务的时候，根据redo log进行重做，从而达到事务的持久性这一特性。它存在于InnoDB存储引擎层，如果不采用InnoDB存储引擎，则不具备redo log的相关功能。

2 bin log

2.1 为什么需要bin log

在操作数据库时，如果我们想知道mysql已经更新的事件操作，包括DDL和DML语句和更新的时间点，我们就需要一个日志进行这些记录，在MySQL的Server层中，有一个极其重要的归档日志，称为binlog。

2.2 什么时候产生

事务提交的时候，一次性将事务中的sql语句（一个事物可能对应多个sql语句）按照一定的格式记录到binlog中。

这里与redo log很明显的差异就是redo log并不一定是在事务提交的时候刷新到磁盘，redo log是在事务开始之后就开始逐步写入磁盘。

因此对于事务的提交，即便是较大的事务，提交（commit）都是很快的，但是在开启了bin_log的情况下，对于较大事务的提交，可能会变得比较慢一些。

这是因为binlog是在事务提交的时候一次性写入的造成的，这些可以通过测试验证。

2.3 什么时候释放

binlog的默认是保持时间由参数expire_logs_days配置，也就是说对于非活动的日志文件，在生成时间超过expire_logs_days配置的天数之后，会被自动删除。

2.4 bin log 作用

binlog作为归档日志，它存储了语句的原始逻辑，其主要有两种模式：statement模式和row模式。statement模式记录的是原始sql语句，而row模式记录的是数据行的内容。这意味着，如果需要回滚数据库表，或者进行数据库扩容，binlog将起到重要的作用。

通过binlog和redo log的结合，我们可以将MySQL的状态恢复到这两个日志所保存的任意时间点的状态。

3 undo log

3.1 为什么需要undo log

数据库事务四大特性中有一个是 原子性 ，具体来说就是 原子性是指对数据库的一系列操作，要么全部成功，要么全部失败，不可能出现部分成功的情况。为了保证事务操作的原子性，我们需要在事务开始之前记录事务开始前的状态，用于事务失败时的回滚操作，这就是undo log。

3.2 什么时候产生

事务开始之前，将当前是的版本生成undo log，undo 也会产生 redo 来保证undo log的可靠性

3.3 什么时候释放

当事务提交之后，undo log并不能立马被删除，而是放入待清理的链表，由purge线程判断是否由其他事务在使用undo段中表的上一个事务之前的版本信息，决定是否可以清理undo log的日志空间。

3.4 undo log的作用

undo log保存了事务发生之前的数据的一个版本，可以用于回滚，同时可以提供多版本并发控制下的读（MVCC），也即非锁定读。它存在于InnoDB存储引擎层，如果不采用InnoDB存储引擎，则不具备undo log的相关功能。

4 mysql执行更新操作过程图解