undo和redo介绍

在数据库系统中，既有存放数据的文件，也有存放日志的文件。日志在内存中也是有缓存Log buffer，也有磁盘文件log file。
MySQL中的日志文件，有这么两类与事务有关：undo日志与redo日志。

1、undo日志

数据库事务具备原子性（Atomicity），如果事务执行失败，需要把数据回滚。
事务同时还具备持久性(Durability)，事务对数据所做的变更就完全保存在了数据库，不能因为故障而丢失。
持久性和原子性可以利用undo日志来实现。

Undo Log的原理很简单，为了满足事务的原子性，在操作任何数据之前，首先将数据备份到Undo Log。然后进行数据的修改。如果出现了错误或者用户执行了ROLLBACK语句，系统可以利用Undo Log中的备份将数据恢复到事务开始之前的状态。

数据库写入数据到磁盘之前，会把数据先缓存在内存中，事务提交时才会写入磁盘中。

用Undo Log实现原子性和持久化的事务的简化过程：

假设有A、B两个数据，值分别为1,2。
A. 事务开始.
B. 记录A=1到undo log buffer.
C. 修改A=3.
D. 记录B=2到undo log buffer.
E. 修改B=4.
F. 将undo log buffer写到磁盘。
G. 将数据写到磁盘。
H. 事务提交

• 如何保证原子性？
  在修改数据到磁盘前，会先记录undo log，并将undo log持久化到硬盘
• 如何保证持久性？
  在事务提交之前，把内存中缓存的数据写入磁盘。这样事务提交时，可以确定数据是已经持久化的，不会丢失。
• 若系统在G和H之间崩溃
  此时事务并未提交，需要回滚。而undo log已经被持久化，可以根据undo log来恢复数据
• 若系统在G之前崩溃
  此时数据并未持久化到硬盘，依然保持在事务之前的状态

缺陷：每个事务提交前将数据和Undo Log写入磁盘，这样会导致大量的磁盘IO，因此性能很低。

如果能够将数据缓存一段时间，就能减少IO提高性能。但是这样就会丧失事务的持久性。因此引入了另外一种机制来实现持久化，即Redo Log.

2、redo日志

和Undo Log相反，Redo Log记录的是新数据的备份。在事务提交前，只要将Redo Log持久化即可，不需要将数据持久化，减少了IO的次数。

先来看下基本原理：

Undo + Redo事务的简化过程

假设有A、B两个数据，值分别为1,2

A. 事务开始.
B. 记录A=1到undo log.
C. 修改A=3.
D. 记录A=3到redo log.
E. 记录B=2到undo log.
F. 修改B=4.
G. 记录B=4到redo log.
H. 将undo log写入磁盘
I. 将redo log写入磁盘
J. 事务提交

安全和性能问题

• 如何保证原子性？
  如果在事务提交前故障，通过undo log日志恢复数据。如果undo log都还没写入，那么数据就尚未持久化，无需回滚
• 如何保证持久化？
  大家会发现，这里并没有出现数据的持久化。因为数据已经写入redo log，而redo log持久化到了硬盘，因此只要到了I以后，事务是可以提交的。
• 内存中的数据库数据何时持久化到磁盘？
  因为redo log已经持久化，因此数据库数据写入磁盘与否影响不大，不过为了避免出现脏数据（内存中与磁盘不一致），事务提交后也会将内存数据刷入磁盘（也可以按照固设定的频率刷新内存数据到磁盘中）。
• 持久化redo和持久化数据库数据有什么性能差异？
  • 数据库数据写入是随机IO，性能很差
  • redo log在初始化时会开辟一段连续的空间，写入是顺序IO，性能很好
• redo log中记录的数据，有可能尚未提交，那么如何完成数据恢复？
  数据恢复有两种策略：
  • 恢复时，只重做已经提交了的事务
  • 恢复时，重做所有事务包括未提交的事务和回滚了的事务。然后通过Undo Log回滚那些未提交的事务
    Inodb引擎采用的是第二种方案，因此undo log要在 redo log前持久化
• 写入性能的优化
  事务提交前需要同时写入undo log和 redo log，势必增加IO次数，因此实际上undo log并不是直接写入磁盘，而是先写入到redo log中，当redo log持久化时，undo log就同时持久化到硬盘了。
  因此事务提交前，只需要对redo log持久化即可。
  另外，redo log并不是写入一次就持久化一次，redo log在内存中也有自己的缓冲池：redo log buffer。每次写redo log都是写入到buffer，在提交时一次性持久化到磁盘，减少IO此时。

最后总结一下：

• undo log 记录更新前数据，用于保证事务原子性
• redo log 记录更新后数据，用于保证事务的持久性
• redo log有自己的内存buffer，先写入到buffer，事务提交时写入磁盘
• redo log持久化之后，意味着事务是可提交的