9、redo log

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

1. 持久化（崩溃恢复）

• redo log 是 物理日志，记录了某个数据页做了什么修改，比如对 XXX 表空间中的 YYY 数据页 ZZZ 偏移量的地方做了AAA 更新，每当执行一个事务就会产生这样的一条或者多条物理日志。

• 过程：

  • 如果断电的话，内存中的数据就会丢失，为了解决这个问题，我们需要使用 redo log：当修改某个页时，我们先把内存中的这个页标记为脏页，然后把这个操作写入 redo log。

  • 在之后的某个时间，引擎会将把内存上的脏页刷新到磁盘上，也就是WAL （Write-Ahead Logging）技术：

    

    （WAL 技术指的是， MySQL 的写操作并不是立刻写到磁盘上，而是先写日志，然后在合适的时间再写到磁盘上。所以说，redo log是立即写的，而磁盘却不是。)

  • 事务提交时，再把redo log 刷新到磁盘上

  • 所以有了 redo log，再通过 WAL 技术，InnoDB 就可以保证即使数据库发生异常重启，之前已提交的记录都不会丢失，这个能力称为 crash-safe（崩溃恢复）

• 易错点：

  ① undo log 也要持久化到 redo log：

  • 每生成一条undo log，都会在内存中修改Undo页面。只要是对内存中的页面进行改动，都需要用 redo log 来持久化，Undo页面也不例外。所以这个Undo页面的修改操作将记录到 redo log 中

  ② redo log 和 undo log 区别：

  • redo log 记录了此次事务**「修改后」的数据状态**，记录的是更新之后的值，主要用于事务崩溃恢复，保证事务的持久性。
  • undo log 记录了此次事务**「修改前」的数据状态**，记录的是更新之前的值，主要用于事务回滚，保证事务的原子性。

  ③ redo log 和 undo log 共同使用时的流程：

  • 事务提交之前发生了崩溃（这里的崩溃不是宕机崩溃（如断电），而是事务执行错误，mysql 还是正常运行的),重启后会通过 undo log 回滚事务。如果是宕机崩溃的话，其实就不需要通过 undo log 回滚了，因为事务没有提交，事务的数据并不会持久化，还是在内存中，宕机崩溃了数据就丢失了，反正事务都没有提交成功，所以数据本身就无意义的，丢失了就丢失了。

  • 事务提交之后发生了崩溃（这里的崩溃是宕机崩溃），重启后会通过 redo log 恢复事务，如下图：

    

    ​ （也就是说，事务提交之前断电的话，里面的数据不会被持久化）

2. 提高数据库写入磁盘的性能

• 如果不借用 redo log，那么直接将数据写入磁盘 是 随机写；而将redo log写入磁盘时，会让redo log按顺序一个一个追加到 日志文件末尾，所以是 顺序写。而磁盘的顺序写 比 随机写 的性能高效得多，所以说redo log提升了 MySQL 写入磁盘的性能
  

• 易错点：

  ① redo log并不是直接写入磁盘的，而是先写入redo log缓存中**（redo log buffer）**，后续再持久化到磁盘中，从而减少IO操作。对于何时将 redo log bufffer 写入缓存，由 innodb_flush_log_at_trx_commit 控制：

  

  • 也就是当参数为1时，才是正常操作（即在事务提交时刷盘），参数为0或2时，及时事务提交，redo log buffer 也不会刷盘，而是放在内存的不同位置，最后又后台进程每隔一秒读取并刷盘。

  • 所以说，参数为0是最危险的，参数为2也比较危险，参数为1才是安全的。但是对于写入的性能，却是完全相反，即性能：0>2>1。

  ② 「重做日志文件组」由有 2 个 redo log 文件组成，这两个 redo 日志的文件名叫 ：ib_logfile0 和 ib_logfile1。重做日志文件组是以循环写的方式工作的，从头开始写，写到末尾就又回到开头，相当于一个环形。

  

  当redo log 文件写满了，数据库就会阻塞，直到将 内存中的脏页刷新到磁盘，这个时候就可以循环覆盖掉一开始的redo log了，也就是 redo log 文件可以继续写了，则数据库恢复运行。