Undo Log（回滚日志）
实现原理与分类
原理：Undo Log 记录的是数据修改前的旧值，通过这些旧值可以将数据恢复到修改之前的状态。它采用的是逻辑日志，即记录的是如何撤销操作，而不是物理数据的实际值。
分类：在 InnoDB 存储引擎中，Undo Log 分为两种类型，分别是插入 Undo Log（Insert Undo Log）和更新 Undo Log（Update Undo Log）。
- 插入 Undo Log 是在插入操作时产生的，当事务提交后，该日志可以被立即删除，因为插入操作只影响当前事务，不会对其他事务产生影响；
- 更新 Undo Log 是在更新或删除操作时产生的，它不仅用于事务回滚，还用于实现多版本并发控制（MVCC），所以不能立即删除，需要在满足一定条件（如没有其他事务需要读取该版本数据）后才能被清理。
作用场景
事务回滚 ：当事务执行过程中出现错误或者用户手动回滚事务时，通过 Undo Log 可以将数据恢复到事务开始之前的状态。
MVCC（多版本并发控制）：在并发环境下，不同的事务可能会同时访问和修改同一数据。MVCC 利用 Undo Log 为每个事务提供一个数据的快照，使得事务可以看到不同版本的数据，从而实现并发事务之间的隔离。
Redo Log（重做日志）
日志组与循环写入
日志组：Redo Log 通常由多个文件组成一个日志组，例如 ib_logfile0、ib_logfile1 等。这些文件按照顺序循环使用，当一个日志文件写满后，会自动切换到下一个文件继续写入。
循环写入：Redo Log 采用循环写入的方式，即当所有日志文件都写满后，会回到第一个文件重新开始写入。这种方式可以避免日志文件无限增长，同时也提高了日志文件的利用率。
刷盘策略
innodb_flush_log_at_trx_commit 参数控制了 Redo Log 的刷盘策略，有三个可选值：
-
0：表示每秒将 Redo Log 缓冲区的内容刷写到磁盘一次，事务提交时不会立即刷盘。这种方式性能最高，但在系统崩溃时可能会丢失最多 1 秒的数据修改。
-
1：表示每次事务提交时都将 Redo Log 缓冲区的内容刷写到磁盘，这是最安全的策略，但性能相对较低。
-
2：表示每次事务提交时将 Redo Log 缓冲区的内容写入操作系统的文件系统缓存，但不立即刷写到磁盘，操作系统会每秒将文件系统缓存的内容刷写到磁盘。这种方式在系统崩溃时可能会丢失部分未刷盘的数据，但性能介于 0 和 1 之间。
Binlog（二进制日志）
日志格式
STATEMENT：基于 SQL 语句的日志格式，它记录的是 SQL 语句本身。这种格式的优点是日志文件较小，占用空间少，但在某些情况下可能会导致主从数据不一致，例如使用了一些不确定的函数（如 NOW()、RAND() 等）。
ROW：基于行的日志格式，它记录的是每一行数据的修改情况。这种格式可以保证主从数据的一致性，但日志文件较大，占用空间多。
MIXED：混合日志格式，MySQL 会根据具体的 SQL 语句自动选择合适的日志格式。对于大多数情况，会使用 ROW 格式；对于一些不会导致主从数据不一致的 SQL 语句，会使用 STATEMENT 格式。
日志过期与清理
Binlog 文件会随着时间的推移不断增长，为了避免占用过多的磁盘空间，需要定期清理过期的 Binlog 文件。可以通过设置 expire_logs_days 参数来指定 Binlog 文件的保留天数，超过该天数的 Binlog 文件会被自动删除。另外，也可以使用 PURGE BINARY LOGS 命令手动清理指定的 Binlog 文件。
