MySQL的redo log

        MySQL 的 redo log 是一种用于保证数据库事务一致性的日志机制，属于 InnoDB 存储引擎 中的一部分，它在数据库发生变更时记录事务的操作，用来在数据库崩溃时恢复数据的一致性。redo log 主要是为了解决 崩溃恢复 问题，确保事务即使在发生崩溃的情况下也不会丢失。

1. Redo Log 的工作原理

InnoDB 的 redo log 在磁盘中分为两个文件：ib_logfile0 和 ib_logfile1，这些文件按大小限制并且是循环使用的。(ib_logfile0写满后写ib_logfile1）

事务提交前的步骤：

1. 日志写入：当事务对数据做出修改时，InnoDB 会将修改的内容（例如插入、更新或删除的数据）记录到 redo log 中，而不是直接修改磁盘上的数据页。
2. flush 到磁盘：日志首先会被写入内存中的 redo log buffer 中。当事务提交时，InnoDB 会强制将 redo log buffer 中的内容写入磁盘中的 redo log 文件。
3. 提交事务：一旦 redo log 写入磁盘，事务就被认为是提交的。

崩溃恢复：

当 MySQL 重启后，InnoDB 会扫描 redo log 文件，将未完全应用的操作重新应用到数据文件上。这样可以保证事务的持久性，即使数据库在事务提交前崩溃，也不会丢失已提交事务的数据。

2. Redo Log 的特点

        1.顺序写入：redo log 是顺序写入的，具有高效的写性能。

        2.写前日志：redo log 是基于写前日志（Write-Ahead Logging, WAL）机制的，即修改操作先写日志，再写数据文件。

        3.持久性保证：通过将修改记录到 redo log，保证了数据库的持久性，即使系统崩溃，也可以通过 redo log 恢复未保存的操作。

3.一次更新操作流程

有人说MySQL只要事务提交了就一定能够保证事务四大特性（ACID）中的持久性，但是这还要看一个配置innodb_flush_log_at_trx_commit参数，它决定了redolog的刷盘策略：

1：每次事务提交时，都会将 redo log 刷写到磁盘，这能保证事务的强持久性，但会影响性能。

2：每次事务提交时，都会将 redo log 写入操作系统的缓冲区，但不立即刷写到磁盘。这种模式下，系统崩溃时可能丢失一些数据。

0：每次提交事务时不刷盘。

另外，Innodb存储引擎有一个后台线程，每隔1秒，就会把会redo log buffer中的内容写入到文件系统缓存page cache，然后调用fsync刷盘。

１.innodb_flush_log_at_trx_commit参数默认为１，redolog在调用系统的fsync完全同步到file中才返回事务提交成功。

２.如果设置为２，将 redo log 写入操作系统的缓冲区就返回事务提交成功了，如果这个时候服务器宕机，MySQL就可能丢失１秒的数据

３.如果设置为０，无论是MySQL挂了还是服务器宕机都可能会丢失１秒的数据。

只要是要保证事务，就应该设置为１，如果可以接受事务的缺失为代价来减少IO、提高性能可以选择２或０（不建议）。

４. Redo Log 与 Binlog 的区别

MySQL 还有另一种日志：binlog（binary log）。虽然这两者都用于事务日志，但它们的用途不同：

１.redo log：记录的是数据库的物理更改，是用来恢复崩溃时数据的一致性。在innoDB引擎层。

２.binlog：记录的是逻辑操作，主要用于复制和恢复数据。在server层