Redo日志和Undo日志

╰半橙微兮° 2023-10-09 15:04 27阅读 0赞

#### Redo日志和Undo日志 ####

*  Redo日志和Undo日志
 *   *  1 Redo日志和Undo日志概述
     *  2 Redo日志
     *   *  2.1 为什么需要Redo日志
         *  2.2 Redo日志的好处、特点
     *  3 Undo日志
     *   *  3.1 如何理解Undo日志
         *  3.2 Undo日志的作用

## Redo日志和Undo日志 ##

### 1 Redo日志和Undo日志概述 ###

**事务**有4种特性：`原子性`、`一致性`、`隔离性`和`持久性`。那么事务的四种特性到底是基于什么机制实现呢？

*  事务的**隔离性**由 锁机制 实现。
 *  而事务的**原子性**、**一致性**和**持久性**由事务的 `redo 日志`和`undo 日志`来保证。  
    **①**REDO LOG 称为**重做日志** ，提供再写入操作，恢复提交事务修改的页操作，用来保证事务的持久性。  
    **②**UNDO LOG 称为 **回滚日志** ，回滚行记录到某个特定版本，用来保证事务的原子性、一致性。
 *  有的DBA或许会认为UNDO是REDO的逆过程，其实不然。**REDO和UNDO都可以视为是一种恢复操作**，但是：
 *  **redo log：** 是存储引擎层(innodb)生成的日志，记录的是**“物理级别”**上的页修改操作，比如页号xxx、偏移量yyy写入了’zzz’数据。主要为了保证数据的可靠性。
 *  **undo log：** 是存储引擎层(innodb)生成的日志，记录的是**逻辑操作**日志，比如对某一行数据进行了INSERT语句操作，那么undo log就记录一条与之相反的DELETE操作。主要用于**事务的回滚**(undo log记录的是每个修改操作的逆操作)和一致性非锁定读(undo log回滚行记录到某种特定的版本—MVCC，即多版本并发控制)。

### 2 Redo日志 ###

#### 2.1 为什么需要Redo日志 ####

**一方面**，缓冲池可以帮助我们消除CPU和磁盘之间的鸿沟，checkpoint机制可以保证数据的最终落盘，然而由于checkpoint 并不是每次变更的时候就触发 的，而是master线程隔一段时间去处理的。所以最坏的情况就是事务提交后，刚写完缓冲池，数据库宕机了，那么这段数据就是丢失的，无法恢复。

**另一方面**，事务包含 持久性 的特性，就是说对于一个已经提交的事务，在事务提交后即使系统发生了崩溃，这个事务对数据库中所做的更改也不能丢失。

**那么如何保证这个持久性呢？**

**一个简单的做法 ：** 在事务提交完成之前把该事务所修改的所有页面都刷新到磁盘，但是这个简单粗暴的做法有些问题。

*  **修改量与刷新磁盘工作量严重不成比例**  
    有时候我们仅仅修改了某个页面中的一个字节，但是我们知道在InnoDB中是以页为单位来进行磁盘to的，也就是说我们在该事务提交时不得不将一个完整的页面从内存中刷新到磁盘，我们又知道一个页面默认是16KB大小，只修改一个字节就要刷新16KB的数据到磁盘上显然是太小题大做了。
 *  **随机IO刷新较慢**  
    一个事务可能包含很多语句，即使是一条语句也可能修改许多页面，假如该事务修改的这些页面可能并不相邻，这就意味着在将某个事务修改的Buffer Pool中的页面刷新到磁盘时，需要进行很多的随机IO，**随机IO比顺序IO要慢**，尤其对于传统的机械硬盘来说。

**另一个解决的思路 ：** 我们只是想让已经提交了的事务对数据库中数据所做的修改永久生效，即使后来系统崩溃，在重启后也能把这种修改恢复出来。所以我们其实没有必要在每次事务提交时就把该事务在内存中修改过的全部页面刷新到磁盘，只需要把修改了哪些东西 记录一下 就好。比如，某个事务将系统表空间中 第10号 页面中偏移量为 100 处的那个字节的值 1 改成 2 。我们只需要记录一下：将第0号表空间的10号页面的偏移量为100处的值更新为 2 。

![在这里插入图片描述][3db7584bc6d1468ca59ba5d5ef2ff7bc.png]

#### 2.2 Redo日志的好处、特点 ####

1.  **好处**

*  redo日志降低了刷盘频率
 *  redo日志占用的空间非常小

1.  **特点**

*  redo日志是顺序写入磁盘的
 *  事务执行过程中，redo log不断记录

### 3 Undo日志 ###

**redo log是事务持久性的保证，undo log是事务原子性的保证。在事务中更新数据的前置操作其实是要先写入一个undo log。**

#### 3.1 如何理解Undo日志 ####

事务需要保证 原子性 ，也就是事务中的操作要么全部完成，要么什么也不做。但有时候事务执行到一半会出现一些情况，比如：

*  情况一：事务执行过程中可能遇到各种错误，比如 服**务器本身的错误** ， **操作系统错误** ，甚至是突然**断电**导致的错误。
 *  情况二：程序员可以在事务执行过程中手动输入 `ROLLBACK` 语句结束当前事务的执行。  
    以上情况出现，我们需要把数据改回原先的样子，这个过程称之为 回滚 ，这样就可以造成一个假象：这个事务看起来什么都没做，所以符合 **原子性** 要求。

以上情况出现，我们需要把数据改回原先的样子，这个过程称之为回滚，这样就可以造成一个假象：这个事务看起来什么都没做，所以符合原子性要求。

每当我们要对一条记录做改动时(这里的**改动**可以指`INSERT、 DELETE`、`UPDATE`)，都需要"“留一手” -----把回滚时所需的东西记下来。比如:

*  你**插入一条记录**时，至少要把这条记录的主键值记下来，之后回滚的时候只需要把这个主键值对应的**记录删掉**就好了。(对于每个INSERT， InnoDB存储引擎会完成一个DELETE)
 *  你**删除了一条记录**，至少要把这条记录中的内容都记下来，这样之后回滚时再把由这些内容组成的记录**插入**到表中就好了。(对于DELETE,InnoDB存储引擎会执行一个INSERT)
 *  你**修改了一条记录**，至少要把修改这条记录前的旧值都记录下来，这样之后回滚时再把这条记录**更新为旧值**就好了。(对于每个UPDATE，InnoDB存储引擎会执行一个相反的UPDATE，将修改前的行放回去)

MySQL把这些为了回滚而记录的这些内容称之为**撤销日志**或者**回滚日志****(即undo log)**。注意，由于查询操作( SELECT）并不会修改任何用户记录，所以在查询操作执行时，并不需要记录相应的undo日志。

**此外，undo log会产生redo log，也就是undo log的产生会伴随着redo log的产生，这是因为undo log也需要持久性的保护。**

#### 3.2 Undo日志的作用 ####

*  **作用1：回滚数据**  
    用户对undo日志可能有误解：undo用于将数据库物理地恢复到执行语句或事务之前的样子。但事实并非如此。undo是逻辑日志，因此只是将数据库逻辑地恢复到原来的样子。所有修改都被逻辑地取消了，但是数据结构和页本身在回滚之后可能大不相同。  
    这是因为在多用户并发系统中，可能会有数十、数百甚至数千个并发事务。数据库的主要任务就是协调对数据记录的并发访问。比如，一个事务在修改当前一个页中某几条记录，同时还有别的事务在对同一个页中另几条记录进行修改。因此，不能将一个页回滚到事务开始的样子，因为这样会影响其他事务正在进行的工作。
 *  **作用2：MVCC**  
    undo的另一个作用是MVCC，即在InnoDB存储引擎中MVCC的实现是通过undo来完成。当用户读取一行记录时，若该记录已经被其他事务占用，当前事务可以通过undo读取之前的行版本信息，以此实现非锁定读取。

[3db7584bc6d1468ca59ba5d5ef2ff7bc.png]: https://img-blog.csdnimg.cn/3db7584bc6d1468ca59ba5d5ef2ff7bc.png