MySQL 日志：Undo Log、Redo Log、Binlog

MySQL的日志有三种：Undo Log、Redo Log、Binlog，它们各自扮演着不同的角色。

Undo Log（回滚日志）：

Undo Log记录的是MySQL对于InnoDB存储引擎上操作数据时所做的修改，在数据被读取和修改的过程中，Undo Log会记录修改细节，当数据发生故障或其他异常情况时，Undo Log可以通过回滚的方式让数据恢复到之前的某个状态。Undo Log的作用是在事务回滚时，可以通过回滚变换将数据库恢复到操作前的状态。

另外，undo log 还有一个作用，通过 ReadView + undo log 实现 MVCC（多版本并发控制）。

对于「读提交」和「可重复读」隔离级别的事务来说，它们的快照读（普通 select 语句）是通过 Read View + undo log 来实现的，它们的区别在于创建 Read View 的时机不同：

• 「读提交」隔离级别是在每个 select 都会生成一个新的 Read View，也意味着，事务期间的多次读取同一条数据，前后两次读的数据可能会出现不一致，因为可能这期间另外一个事务修改了该记录，并提交了事务。
• 「可重复读」隔离级别是启动事务时生成一个 Read View，然后整个事务期间都在用这个 Read View，这样就保证了在事务期间读到的数据都是事务启动前的记录。

这两个隔离级别实现是通过「事务的 Read View 里的字段」和「记录中的两个隐藏列（trx_id 和 roll_pointer）」的比对，如果不满足可见行，就会顺着 undo log 版本链里找到满足其可见性的记录，从而控制并发事务访问同一个记录时的行为，这就叫 MVCC（多版本并发控制）。

因此，undo log 两大作用：

• 实现事务回滚，保障事务的(ACID)原子性。事务处理过程中，如果出现了错误或者用户执 行了 ROLLBACK 语句，MySQL 可以利用 undo log 中的历史数据将数据恢复到事务开始之前的状态。
• 实现 MVCC（多版本并发控制）关键因素之一。MVCC 是通过 ReadView + undo log 实现的。undo log 为每条记录保存多份历史数据，MySQL 在执行快照读（普通 select 语句）的时候，会根据事务的 Read View 里的信息，顺着 undo log 的版本链找到满足其可见性的记录。

---

Redo Log（重做日志）：

redo log 是 MySQL 数据库中的一种重要的日志文件，它用来记录在事务提交之前对数据文件所做的修改，以实现事务的持久性和原子性。redo log 的作用类似于操作系统的事务日志，是数据库崩溃恢复的关键组成部分之一。

具体来说，当一个事务被提交时，操作系统将该事务所做的所有修改写入 redo log 中。这些修改将在数据库文件上被实际执行之前被写入磁盘。因此，如果出现崩溃或故障，在系统恢复时可以使用 redo log 来回滚未提交的事务并将数据文件恢复到原始状态。此外，redo log 还可以帮助数据库在故障或崩溃后恢复其数据完整性。

Redo Log记录的是InnoDB的事务日志，所有InnoDB数据文件的修改操作，都被记录在这个日志里，Redo Log的记录形式是“物理日志”。

当MySQL发生故障时，比如断电，机器故障等，InnoDB存储引擎会重新执行Redo Log中的操作，把数据恢复到原来的状态。

redo log 和 undo log 区别在哪？

• redo log 记录了此次事务「完成后」的数据状态，记录的是更新之后的值；
• undo log 记录了此次事务「开始前」的数据状态，记录的是更新之前的值；

---

Binlog（二进制日志）：

前面的两个日志都是存储引擎生成的，而Binlog日志是Server层生成的语句

用于记录数据库中的所有数据修改操作（不会记录查询类的操作，比如 SELECT 和 SHOW 操作。）。主要用途如下：

1. 数据恢复：binlog可用于进行数据恢复，尤其是在出现数据误操作或者灾难性事件后，可以基于binlog进行数据恢复。

2. 数据复制和主从同步：binlog可以被用来复制数据，然后在另一个MySQL实例中重放这些日志以实现主从同步的目的。

3. 数据库备份：在备份MySQL数据库的时候，binlog也通常会被备份。备份的binlog可用于数据恢复以及数据复制和主从同步。

4. 数据库安全：binlog可记录所有对数据库的修改，包括谁、何时、何地进行了什么修改。这些信息可用于进行安全审计以及检测和修复潜在的安全漏洞。

5. 数据库性能调优：binlog可记录所有对数据库的操作以及查询，可以用于分析查询性能和数据库性能问题。

为什么有了 binlog， 还要有 redo log？

最开始 MySQL 里并没有 InnoDB 引擎，MySQL 自带的引擎是 MyISAM，但是 MyISAM 没有 crash-safe 的能力，binlog 日志只能用于归档。

而 InnoDB 是另一个公司以插件形式引入 MySQL 的，既然只依靠 binlog 是没有 crash-safe 能力的，所以 InnoDB 使用 redo log 来实现 crash-safe 能力。

 redo log 和 binlog 有什么区别？

Redo log 和 binlog 都是 MySQL 中的日志文件，但它们的作用和机制不同。

Redo log （重做日志）是 InnoDB 存储引擎专有的，用来实现事务的持久性和崩溃恢复，记录了 InnoDB 存储引擎中所有的数据修改操作，包括插入、更新、删除等操作。每当事务提交时，Redo log 都会将这个事务的所有修改操作记录到日志中，并确保其持久到磁盘上。当 MySQL 重新启动时，InnoDB 存储引擎会通过 Redo log 中的记录来进行崩溃恢复，恢复到最近一次事务提交之后的状态。

Binlog （归档日志）则是 MySQL 的服务器层实现的，用于记录数据库的所有修改操作，包括基于事务的和非事务的操作。Binlog 记录的内容更加详细，不仅包括 Redo log 中的操作，还包括数据变更前后的值。Binlog 默认情况下不是实时写入，而是在事务提交后才写入。Binlog 的主要作用是用于数据复制、备份和恢复。

总结来说，Redo log 主要用于实现 InnoDB 存储引擎的事务机制，确保数据发生修改时的持久性和崩溃恢复；而 Binlog 则主要用于数据的复制、备份和恢复。

Binlog记录的是原始的SQL语句，Binlog的作用是在进行MySQL Master-Slave复制时，可以将Binlog同步到Slave服务器上去，从而让所有的Slave数据库与Master数据库保持数据一致。

由于Binlog只记录SQL语句，并不记录数据的物理变化，因此，Binlog的重放需要根据数据库中的数据状态逐条重放SQL，而不是像Redo Log一样底层操作累积，在重放时再一次地恢复整个数据库的状态。

在实际应用中，Undo Log、Redo Log和Binlog是相互协作的，它们各自扮演重要的角色，来保证MySQL数据库的运行稳定性和数据一致性。