当前位置：首页 > news >正文

redo log 日志与 undo log 日志工作原理

news 2024/10/26 5:53:48

目录标题

1. redo log 日志
2. undo log 日志
3.总结

在这里插入图片描述

1. redo log 日志

redo log日志是 MySQL 数据中的重要日志之一，其本质是物理日志，存放于数据库的数据目录中，名称为： ib_logfile 。它的功能主要是用于存放脏数据的日志（注：脏数据是数据库中刚产生的还没来得及写入磁盘的新数据），当数据发生故障时保证数据不丢失。需要说明的是：事务提交时修改磁盘的数据仍然是 Buffer Pool 中的数据，redo log 只是为了保证 Buffer Pool 中新修改的数据不丢失，进而保证事务提交时的数据完整性，不能笼统地认为 redo log 是保存提交的数据的。

物理日志（如Redo Log）：
记录的是数据页的物理变化，即实际的数据块的内容。
用于在系统崩溃后恢复未完成的事务。
例如，Redo Log记录了数据页从状态A变为状态B的具体字节变化。

为了数据安全，MySQL 数据库在运行的过程中，时时刻刻都在产生 redo log。

新更新的数据会首先写入 Buffer Pool 和 redo log 之中，然后当事务提交时才会写入磁盘，也就是说各种数据修改首先统一写入 Buffer Pool 和 redo log 之中，然后再统一写入磁盘。Buffer Pool 中的数据写入磁盘文件是受innodb_flush_log_at_trx_commit控制的，其配置的值为：0、1 和 2。其详细情况如下：

当配置为 0 时，主要受 InnoDB 存储引擎中的 Master 线程的周期控制，一般是一秒或十秒刷新一次。
当配置为 1 时，一旦事务提交，Buffer Pool 和 redo log 中的数据将立即写入磁盘，此时即便数据库宕机数据也能恢复，比较安全，但是可能会造成一定程度上的延时。
当配置为 2 时，事务提交，数据不会立即写入磁盘，此时如果数据库宕机，则可能会丢失部分数据，优点就是性能比较高。但是每次修改数据，redo log 中的数据都会有一个标识，这个标识叫 checkpoint，当数据库发生宕机时，数据是从最近的 checkpoint 中恢复数据的，最大程度减少数据丢失。

数据库中的innodb_flush_log_at_trx_commit的值可以使用下方的方法查询：

mysql> show global variables like 'innodb_flush_log_at_trx_commit';
+--------------------------------+-------+
| Variable_name                  | Value |
+--------------------------------+-------+
| innodb_flush_log_at_trx_commit | 1     |
+--------------------------------+-------+
1 row in set (0.01 sec)

默认设置：MySQL 的默认设置通常是 innodb_flush_log_at_trx_commit = 1，这是为了确保数据的安全性。

生产环境：在生产环境中，根据应用的具体需求来选择合适的设置。对于大多数应用来说，innodb_flush_log_at_trx_commit = 2 是一个比较平衡的选择。

2. undo log 日志

undo log 是 MySQL 数据库中另一个重要的日志之一，其本质是一个逻辑日志，存放于 MySQL 数据库的表空间之中，也就是内存之中。它的主要作用是用于数据回滚。

逻辑日志是指记录了数据修改前的状态或逻辑操作的日志，而不是直接记录数据页的物理变化。具体来说，逻辑日志记录的是数据的旧值以及如何恢复这些旧值的操作。

当发了红包时，如果数据库恰巧发生故障，为了保证数据的安全（及修改的数据不会只修改一部分），就需要使用到数据的回滚，这时 undo log 日志就派上了用场。

**那么你知道undo log是怎么回滚日志的吗？**对于数据恢复来说，主要有两种方式，分别是：物理恢复和逻辑恢复，那么undo log就是通过逻辑恢复的方式恢复数据。例如：宋押司发给李逵的红包，发现心有不甘，于是撤回。那么这个过程之中先是INSERT或者UPDATE，将宋押司的 50 块钱INSERT或者UPDATE给李逵，撤回则是将INSERT或者UPDATE转换成DELETE和UPDATE的过程。

上文中我们说了，数据库的事务具有持久性等四个特性，所以一旦事务提交，undo log 中保存的数据也就随即不再需要。但是，此时 undo log 中保存的数据并不是立即删除，而是像垃圾一样丢弃到数据库中的 undo 链表之中，而后由 MySQL 之中的 purge 线程统一清理删除，这个做法避免了其他事务回滚造成数据错误，同时也提高了数据库的性能。

3.总结

MySQL 数据库的事务主要是由redo log和undo log来实现的，这是我们理解 MySQL 事务原理的关键所在。

redo log是在事务执行之前才产生的，并且在事务执行过程中，redo log也是不断产生，当产生的脏数据全部都写入磁盘之后，redo log随即也就完成了它的使命。
undo log是在事务执行之前产生的，事务回滚时使用undo log日志中的数据覆盖新修改的数据，进而达到事务回滚的效果。需要注意的是，undo log回滚数据之后并不是立即删除的，而是由purge线程去探测可还有其他的事务正在使用该undo log日志，如果有，则保留，给予其他的事务来使用；如果没有，才会清除该undo log，释放空间。