undo log 和redo log 的一点理解

两种log的作用:

• undo log（回滚日志）：是 Innodb 存储引擎层生成的日志，实现了事务中的原子性，主要用于事务回滚和 MVCC。
• redo log（重做日志）：是 Innodb 存储引擎层生成的日志，实现了事务中的持久性，主要用于掉电等故障恢复。

实际使用场景:

redo log:

SQL执行器会执行你发送给MySQL的SQL语句，MySQL为了提高的性能，对于增、删、改这种操作都是在内存中完成的，所谓的内存就是上图中BufferPool。比如上图中的SQL执行器执行了一条update xxx where id = 1语句，然后这个id = 1数据行所在的数据页就会被你修改成脏数据页。

此外MySQL还有专门的后台线程等其他机制负责将脏数据页刷新同步回磁盘。

MySQL使用redo log 修改的数据没同步回磁盘时，重启时解析redo log中的事务然后重放一遍。将Buffer Pool中的缓存页重做成脏页。后续再在合适的时机将该脏页刷入磁盘。

• 什么时候产生

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

• 什么时候释放

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

• redo log的刷盘时机

事务提交时，率先将redo log持久化进磁盘。

那你如何控制MySQL，让MySQL在Commit事务时率先将redo log持久化呢？

MySQL提供了参数innodb_flush_log_at_trx_commit

该参数有几个选项：0、1、2

• 想要保证ACID四大特性推荐设置为1：表示当你commit时，MySQL必须将rodolog-buffer中的数据刷新进磁盘中。确保只要commit是成功的，磁盘上就得有对应的rodolog日志。这也是最安全的情况。

• 设置为0：每秒写一次日志并将其刷新到磁盘。

• 设置为2：表示当你commit时，将redolog-buffer中的数据刷新进OS Cache中，然后依托于操作系统每秒刷新一次的机制将数据同步到磁盘中，也存在丢失的风险。

undo log：

保存了事务发生之前的数据的一个版本，可以用于回滚，同时可以提供多版本并发控制下的读（MVCC），也即非锁定读

在执行undo的时候，仅仅是将数据从逻辑上恢复至事务之前的状态，而不是从物理页面上操作实现的，这一点是不同于redo log的。

• 什么时候产生

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

• 什么时候释放

当事务提交之后，undo log落盘，undo log并不能立马被删除，

而是放入待清理的链表，由purge线程判断是否由其他事务在使用undo段中表的上一个事务之前的版本信息，决定是否可以清理undo log的日志空间。

• 事务是如何回滚的？                                            

举个例子：

对于 insert 类型的sql，会在undo log中记录下方才你insert 进来的数据的ID，当你想roll back时，根据ID完成精准的删除。

对于delete 类型的sql，会在undo log中记录方才你删除的数据，当你回滚时会将删除前的数据insert 进去。

对于update 类型的sql，会在undo log中记录下修改前的数据，回滚时只需要反向update即可。

有一个注意点：因为单纯的insert sql不涉及多MVCC的能力。

所以一旦事务commit，这条insert undo log就可以直接删除了。

什么是双1写入

• 始终设置 innodb_flush_log_at_trx_commit=1

• 如果启用了二进制日志记录，请设置 sync_binlog=1。

这也是大家常说的双1设置。前者保证redolog的不丢失、后者保证了binlog的不丢失。