redolog、undolog和binlog日志文件详解
前言
当谈论MySQL数据库的日志文件时，通常会涉及到三种主要类型：redo log（重做日志）、undo log（回滚日志）和binlog（二进制日志）。每种日志文件都有自己的设计目标、记录内容和写入策略，下面我会逐一介绍它们。
redolog
设计目标
- 保证事务的持久性：Redo Log的主要设计目标是在数据库崩溃或发生故障时，确保已提交的事务对数据库的修改能够被恢复，以保证数据的一致性和持久性。
- 提高性能：通过将数据修改操作写入重做日志，MySQL可以延迟将这些操作同步到磁盘，从而提高数据库的写入性能。
记录内容
- Redo Log中记录了每个事务所做的修改操作，如插入、更新、删除等。这些记录通常以物理日志记录的形式存在，即记录了修改了哪些数据页的哪些字节。
- 除了修改操作的内容外，Redo Log还包含了事务的一些元数据信息，如事务ID、事务状态等。
写入策略
- Redo Log的写入是顺序追加（append）的方式进行的，即将事务的修改操作追加到日志文件的末尾。
- Redo Log采用了WAL（Write-Ahead Logging）的机制，即在事务进行数据修改操作之前，先将对应的修改记录写入Redo Log，然后再将修改应用到内存中的数据页，这样可以确保事务的修改记录先于实际数据的修改被持久化到磁盘。
undolog
设计目标
- 提供事务的回滚支持：Undo Log的主要设计目标是提供事务回滚的支持，即在事务发生错误或被回滚时，能够恢复到事务开始之前的状态。
- 支持MVCC（Multi-Version Concurrency Control）：Undo Log也是MVCC机制的重要组成部分，用于存储事务修改前的数据版本，以支持并发读取和写入。
记录内容
- Undo Log记录了事务对数据的修改操作的逆操作，即对数据进行了什么修改，Undo Log中就记录了如何将数据恢复到修改前的状态。
- Undo Log通常以逻辑日志记录的形式存在，记录了事务对数据的修改操作，如将某行数据修改为何种值、删除了哪些数据等。
写入策略
- Undo Log的写入通常也是顺序追加的方式进行的，将事务的逆操作记录追加到日志文件的末尾。
- Undo Log的写入顺序通常与事务的提交顺序相反，即先写入的事务的Undo Log记录会位于后面，这样可以确保在回滚操作时按照相反的顺序进行恢复。
binlog
设计目标
- 数据复制与恢复：Binlog的主要设计目标是支持数据复制和恢复操作，以实现数据的备份、恢复和主从复制等功能。
- 记录数据库变更：除了用于数据复制外，Binlog还可以用于记录数据库的变更历史，方便进行数据审计和恢复。
记录内容
- Binlog记录了数据库中的修改操作，包括对表的增删改操作以及对表结构的变更操作等。
- Binlog以一种较为简洁的格式记录了每个修改操作的元信息，如操作类型、受影响的表名、修改前后的数据等。
写入策略
- Binlog的写入通常是异步的，即MySQL会将修改操作先写入到Binlog缓冲区中，然后由后台线程将缓冲区中的内容定期写入到Binlog文件中。
- 对于复制从库，Binlog的写入通常会在事务提交后立即进行，以确保从库能够尽快获取到主库的数据变更。
小结
- redo log用来保证事务的原子性和持久性，undo log用来事务回滚以及mvcc的功能，保证了事务的一致性，binlog用来实现数据的备份、恢复和主从复制等功能。
- undo log 是逻辑日志，记录的是数据的逻辑修改信息。redo log 是物理日志，记录的是数据的物理修改信息。
- undo log 仅用于回滚事务，不会被用于数据库恢复。redo log 既可以用于回滚事务，也可以用于数据库恢复。