Redo Log（重做日志）
为什么需要 Redo Log？
1. 崩溃恢复
- 数据库崩溃时，系统通过 Redo Log 来恢复尚未写入磁盘的数据。Redo Log 记录了所有已提交事务的操作，系统在重启后会重做这些操作，以保证数据不会丢失。
-
2. 提高性能
- 使用 Redo Log 可以避免每次修改都立即写入磁盘（随机写），而是先将修改操作写入 Redo Log（顺序写），然后将数据写入内存，最后再异步地将数据写入磁盘，减少了磁盘 I/O 的次数，提高了性能。
3. 事务一致性
- 即使数据库在执行过程中崩溃，Redo Log 也可以帮助恢复所有已提交的事务，确保数据库恢复到一致（Consistency）的状态。
Redo Log 是什么？
- Redo Log 是物理日志，记录了某个数据页做了什么修改，如对
AAA表空间中的BBB数据页CCC偏移量的地方做了DDD更新，每当执行一个事务，就会产生一条或多条物理日志。 - 在事务提交时，只要保证 Redo Log 被持久化到磁盘即可，可以不需要等到将缓存在 Buffer Pool 里的脏页数据持久化到磁盘。即使系统崩溃，Redo Log 已完成持久化，等待 MySQL 重启后，可以根据 Redo Log 的内容，将所有数据恢复到最新状态。
WAL（Write-Ahead Logging）技术
核心思想
- 先写日志：修改数据之前，先将修改操作记录到日志文件中，之后择机再写到磁盘中。
- 崩溃恢复：这样即使崩溃，数据也能通过日志恢复到一致的状态。
- 顺序写 VS 随机写：Redo Log 采用顺序循环写的方式，写入磁盘的速度远大于直接写入磁盘的顺序写方式。
过程如图
Redo Log 的持久化过程
1. Redo Log Buffer
- 在事务执行过程中，产生的 Redo Log 也不是直接刷盘的，而是先写入 Redo Log Buffer，后续再择机刷入磁盘中。
- 默认大小为 16MB，可通过
innodb_log_Buffer_size参数动态调整大小，增大时，可以让 MySQL 处理【长事务】时不必写入磁盘，提升写 I/O 性能。 -
2. Redo Log 什么时候刷盘？
缓存在 Redo Log Buffer 中的 Redo Log 还是在内存中，刷盘时机如下：
- MySQL 正常关闭时。
- Redo Log Buffer 中记录的写入量大于总内存空间（由
innodb_log_Buffer_size控制）的一半时，触发落盘。
- 超过一半就落盘的原因：在性能和数据安全之间找到一个平衡点。
- InnoDB 的后台线程每隔 1s，将 Redo Log Buffer 持久化到磁盘。
- 每次提交事务时，将 Redo Log Buffer 持久化到磁盘，由
innodb_flush_log_at_trx_commit参数控制。
3. innodb_flush_log_at_trx_commit 参数
决定 Redo Log 的刷盘时机。
0 ：每次事务提交，将 Redo Log 留在 Redo Log Buffer 中，该模式下，事务提交时不会主动触发落盘操作。
- 写入磁盘时机：等待 InnoDB 后台线程每隔 1s，先写入 OS 的 Page Cache，后调用
fsync()持久化到磁盘。 - 数据安全性：MySQL 崩溃时，会导致上 1s 所有事务数据丢失。
1（默认）：每次事务提交，将缓存在 Redo Log Buffer 中的 Redo Log 直接持久化到磁盘中。
- 安全性：该模式可以保证 MySQL 异常重启后，数据不会丢失。
2：每次事务提交时，都只将缓存在 Redo Log Buffer 中的 Redo Log 写到 Redo Log 文件（OS 的 Page Cache，系统文件缓存），而非磁盘。
- 写入磁盘时机：等待 InnoDB 后台线程每隔 1s，调用
fsync()将 Page Cache 中的 Redo Log 持久化到磁盘。 - 数据安全性：MySQL 崩溃时不会导致数据丢失，只有在 OS 崩溃或系统断电的情况下，丢失上 1s 所有事物数据。
数据安全性对比：参数 1 > 参数 2 > 参数 0
写入性能对比：参数 1 < 参数 2 < 参数 0
每种参数对应的写入过程
4. Redo Log 怎样写入？
重做日志文件组（Redo Log Group）：
- 默认情况下，InnoDB 存储引擎有一个 Redo Log Group，该重做日志文件组由 2 个 Redo Log 文件组成，且每个 Redo Log File 的大小固定且一致，如下图
循环写：
- Redo Log Group 是以循环写方式工作的，即从头开始写，写到末尾再循环到开头，相当于环形。
- 具体过程：Redo Log 是避免防止 Buffer Pool 中的脏页丢失而设计的，但随着系统运行，Buffer Pool 中的脏页逐步被刷新到磁盘中，Redo Log 也需要更新自己的空间，擦除已刷新到磁盘中的旧记录，为新的脏页数据腾出空间。
write pos：Redo Log 当前记录写到的位置。check point：表示当前要擦除的位置。write pos~check point（红色部分）：用来记录新的更新操作。
write pos追上check point时表示 Redo Log 文件已满，这时 MySQL 不能执行新的更新操作，即被阻塞（故大并发量的系统，将 Redo Log 文件大小设置为适当的值很有必要），此时会停下来将 Buffer Pool 中的脏页数据刷新到磁盘中，然后标记 Redo Log 哪些记录可以被擦除，接着对旧 Redo Log 记录进行擦除，等擦除完成并腾出空间后，check point就会往后移动，MySQL 恢复正常，继续执行新的更新操作。
check point~write pos（蓝色部分）：待落盘的脏数据页记录。
- 一次
check point的过程就是脏页数据刷新到磁盘中变成干净页，然后标记 Redo Log 记录中哪些记录可以被覆盖的过程。
