MySQL 事务日志

1. 前言

• 事务有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日志

InnoDB存储引擎是以页为单位来管理存储空间的。在真正访问页面之前，需要把在磁盘上的页缓存到内存中的Buffer Pool之后才可以访问。所有的变更都必须先更新缓冲池中的数据，然后缓冲池中的脏页会以一定的频率被刷入磁盘（ checkPoint机制），通过缓冲池来优化CPU和磁盘之间的鸿沟，这样就可以保证整体的性能不会下降太快。

为什么需要REDO日志

在数据库管理系统中，REDO日志是用来保证数据的持久性的一种机制。当数据库执行写操作时，REDO日志会记录这些操作的详细信息，以确保即使发生系统崩溃等异常情况，数据库也能够在恢复时正确地恢复这些操作。

具体来说，当数据库执行写操作时，它会首先将这些操作写入REDO日志，然后再将它们写入磁盘。这意味着即使在写入磁盘之前发生了系统崩溃，数据库也可以使用REDO日志中的信息来恢复写操作。

此外，REDO日志还可以用于实现事务的持久性和一致性。在事务提交之前，所有的修改操作都会先被记录在REDO日志中，然后再写入磁盘。如果在事务提交之前发生了系统崩溃等异常情况，数据库可以使用REDO日志来恢复未提交的事务，以保证数据的一致性和完整性。

因此，REDO日志对于数据库的安全性和可靠性非常重要，是数据库系统中不可或缺的一部分。

REDO日志的好处、特点

好处

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

存储表空间ID、页号、偏移量以及需要更新的值，所需的存储空间是很小的，刷盘快。

特点

• redo日志是顺序写入磁盘的
  • 在执行事务的过程中，每执行一条语句，就可能产生若干条redo日志，这些日志是按照产生的顺序写入磁盘的，也就是使用顺序IO，效率比随机IO快。
• 事务执行过程中，redo log不断记录
  • redo log跟bin log的区别，redo log是存储引擎层产生的，而bin log是数据库层产生的。
  • 假设一个事务，对表做10万行的记录插入，在这个过程中，一直不断的往redo log顺序记录，而bin log不会记录，直到这个事务提交，才会一次写入到bin log文件中。

redo 的组成

Redo log可以简单分为以下两个部分：

• 重做日志的缓冲 (redo log buffer) ，保存在内存中，是易失的。

  • 参数设置：innodb_log_buffer_size：

    • redo log buffer 大小，默认 16M ，最大值是4096M，最小值为1M。

    mysql> show variables like '%innodb_log_buffer_size%';
    +------------------------+----------+
    | Variable_name | Value |
    +------------------------+----------+
    | innodb_log_buffer_size | 16777216 |
    +------------------------+----------+
    
           
           
             
             
             
             
    
           
           
             
             
             
             
    
              
              
              
              
    1
              
              
              
              
    2
              
              
              
              
    3
              
              
              
              
    4
              
              
              
              
    5
              
              
              
              
    6
             
             
             
             

• 重做日志文件 (redo log file) ，保存在硬盘中，是持久的。

REDO日志文件如图所示，其中的 ib_logfile0 和 ib_logfile1 即为 REDO 日志。

redo的整体流程

以一个更新事务为例，redo log 流转过程，如下图所示：

• 第1步：先将原始数据从磁盘中读入内存中来，修改数据的内存拷贝
• 第2步：生成一条重做日志并写入redo log buffer，记录的是数据被修改后的值
• 第3步：当事务commit时，将redo log buffer中的内容刷新到 redo log file，对 redo log file采用追加写的方式
• 第4步：定期将内存中修改的数据刷新到磁盘中

redo log的刷盘策略

redo log的写入并不是直接写入磁盘的，InnoDB引擎会在写redo log的时候先写redo log buffer，之后以 一定的频率 刷入到真正的redo log file 中。

注意，redo log buffer刷盘到redo log file的过程并不是真正的刷到磁盘中去，只是刷入到 文件系统缓存（page cache）中去（这是现代操作系统为了提高文件写入效率做的一个优化），真正的写入会交给系统自己来决定（比如page cache足够大了）。那么对于InnoDB来说就存在一个问题，如果交给系统来同步，同样如果系统宕机，那么数据也丢失了（虽然整个系统宕机的概率还是比较小的）。

针对这种情况，InnoDB给出 innodb_flush_log_at_trx_commit 参数，该参数控制 commit提交事务时，如何将 redo log buffer 中的日志刷新到 redo log file 中。它支持三种策略：

• 0：表示**事务提交时不将Redo Log刷到磁盘，而是每秒钟将未刷的Redo Log批量刷到磁盘**。这是==最高性能的刷新策略==，但是如果MySQL进程崩溃或机器断电，可能会丢失一秒钟的数据。

  

• 1（默认）：表示**每次事务提交时都将Redo Log同步写入磁盘。这是最安全的刷新策略**，但是性能较差，因为需要等待每个事务提交时都要将Redo Log写到磁盘。

  

• 2：表示**每次事务提交时将Redo Log写入系统缓存（不是磁盘），但是系统会每秒钟将缓存中的Redo Log批量刷到磁盘**。这是一个性能和安全之间的平衡点，能够保证至少每秒钟将Redo Log刷到磁盘，同时避免了每个事务提交时都写入磁盘的性能损失。

  

注意：后台线程每隔一秒都会把 redo log buffer 中的内容写到 page cache，然后调用 fsync 刷盘。

3. Undo日志

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

如何理解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也需要持久性的保护。

undo 日志的作用

• 作用1：回滚数据
  • undo是逻辑日志，因此只是将数据库逻辑地恢复到原来的样子。所有修改都被逻辑地取消了，但是数据结构和页本身在回滚之后可能大不相同。并没有将数据库物理地恢复到执行语句或事务之前的样子。
• 作用2：MVCC
  • undo的另一个作用是MVCC，即在 InnoDB 存储引擎中 MVCC 的实现是通过 undo 来完成。当用户读取一行记录时，若该记录已经被其他事务占用，当前事务可以通过undo读取之前的行版本信息，以此实现非锁定读取。

undo 的存储结构

回滚段与undo页

InnoDB 对 undo log 的管理采用段的方式，也就是回滚段（rollback segment)。每个回滚段记录了1024个undo log segment，而在每个undo log segment段中进行undo页的申请。Undo页则是一种内存缓存区域，用于在事务处理期间存储修改的数据。

• 在InnoDB1.1版本之前(不包括1.1版本)，只有一个rollback segment，因此支持同时在线的事务限制为1024。虽然对绝大多数的应用来说都已经够用。
• 从1.1版本开始 InnoDB 支持最大128个rollback segment，故其支持同时在线的事务限制提高到了128*1024。

mysql> show variables like 'innodb_undo_logs '; # 可以看出 value 为 128

   
   
     
     
     
     

   
   
     
     
     
     

      
      
      
      
1
     
     
     
     

虽然InnoDB1.1版本支持了128个rollback segment，但是这些rollback segment都存储于共享表空间ibdata中。从InnoDB1.2版本开始，可通过参数对rollback segment做进一步的设置。这些参数包括:

• innodb_undo_directory：设置rollback segment文件所在的路径。这意味着rollback segment可以存放在共享表空间以外的位置，即可以设置为独立表空间。该参数的默认值为“.次”，表示当前InnoDB存储引擎的目录。
• Innodb_undo_logs :设置rollback segment的个数，默认值为128。在InnpDB1.2版本中，该参数用来替换之前版本的参数innodb_rollback_segments。
• innodb_undo_tablespaces :设置构成rollback segment文件的数量，这样rollback segment可以较为平均地分布在多个文件中。设置该参数后，会在路径innodb_undo_directory看到undo为前缀的文件，该文件就代表rollback segment文件。

undo log相关参数一般很少改动。

undo 页的重用

当我们开启一个事务需要写undo log的时候，就得先去undo log segment中去找到一个空闲的位置，当有空位的时候，就去申请undo页，在这个申请到的undo页中进行undo log的写入。我们知道mysql默认一页的大小是16k。

为每一个事务分配一个页，是非常浪费的（除非你的事务非常长)，假设你的应用的TPS(每秒处理的事务数目）为1000，那么1s就需要1000个页，大概需要16M的存储，1分钟大概需要1G的存储。如果照这样下去除非MySQL清理的非常勤快，否则随着时间的推移，磁盘空间会增长的非常快，而且很多空间都是浪费的。

于是undo页就被设计的可以重用了，当事务提交时，并不会立刻删除undo页。因为重用，所以这个undo页可能混杂着其他事务的undo log。undo log在commit后，会被放到一个链表中，然后判断undo页的使用空间是否小于3/4，如果小于3/4的话，则表示当前的undo页可以被重用，那么它就不会被回收，其他事务的undo log可以记录在当前undo页的后面。由于undo log是离散的，所以清理对应的磁盘空间时，效率不高。

回滚段与事务

1. 每个事务只会使用一个回滚段，一个回滚段在同一时刻可能会服务于多个事务。

2. 当一个事务开始的时候，会制定一个回滚段，在事务进行的过程中，当数据被修改时，原始的数据会被复制到回滚段。

3. 在回滚段中，事务会不断填充盘区，直到事务结束或所有的空间被用完。如果当前的盘区不够用，事务会在段中请求扩展下一个盘区，如果所有已分配的盘区都被用完，事务会覆盖最初的盘区或者在回滚段允许的情况下扩展新的盘区来使用。

4. 回滚段存在于undo表空间中，在数据库中可以存在多个undo表空间，但同一时刻只能使用一个undo表空间。

mysql> show variables like 'innodb_undo_tablespaces ' ;

#undo log的数量,最少为2，undo log的truncate操作有purge协调线程发起。在truncate某个undo log表空间的过程中，保证有一个可用的undo log可用。

• 1
• 2
• 3

5. 当事务提交时，InnoDB存储引擎会做以下两件事情：
   • 将undo log放入列表中，以供之后的purge操作

     • purge操作其实是为了支持MySQL的MVCC，所以记录不能在事务提交时就立即进行处理，因为可能其他事务正在使用这一行，故InnoDB存储引擎需要保存记录之前的版本。

     • 若该行记录已不被任何其他事务引用，那么就可以进行真正的delete操作，所以可以理解成，purge操作并不是处理当前事务的delete操作，而是去清除之前的delete和update操作，而实际执行的操作只有delete，清理之前行记录的版本

   • 判断undo log所在的页是否可以重用，若可以分配给下个事务使用

回滚段中的数据分类

1. 未提交的回滚数据(uncommitted undo information)：该数据所关联的事务并未提交，用于实现读一致性。所以该数据不能被其他事务的数据覆盖。

2. 已经提交但未过期的回滚数据(committed undo information)：该数据关联的事务已经提交，但是仍受到 undo retention 参数的保持时间的影响。

3. 事务已经提交并过期的数据(expired undo information)：事务已经提交，而且事务保存时间已经超过 undo retention 参数指定的时间，属于已经过期的数据。当回滚段满了后，会优先覆盖“事务已经提交并过期的数据”。

事务提交后并不能马上删除undo log及undo log所在的页。这是因为可能还有其他事务需要通过undo log来得到行记录之前的版本。故事务提交时将undo log放入一个链表中，是否可以最终删除undo log及undo log所在页由purge线程来判断。

undo 的类型

• insert undo log
  • insert undo log是指在insert操作中产生的undo log。因为insert操作的记录，只对事务本身可见，对其他事务不可见(这是事务隔离性的要求)，故该undo log可以在事务提交后直接删除。不需要进行purge操作。
• update undo log
  • update undo log 记录的是对delete和update操作产生的undo log。该undo log可能需要提供MVCC机制，因此不能在事务提交时就进行删除。提交时放入undo log链表，等待purge线程进行最后的删除。

undo log 的生命周期

简要生成过程

以下是undo+redo事务的简化过程
假设有2个数值，分别为A=1和B=2，然后将A修改为3，B修改为4

1. start transaction ;
2．记录 A=1到undo log;
3. update A = 3;
4．记录A=3 到redo log;
5．记录B=2到undo log;
6. update B = 4;
7．记录B =4到redo log;
8．将redo log刷新到磁盘;
9. commit

 
 
   
   
   
   

 
 
   
   
   
   

    
    
    
    
1
    
    
    
    
2
    
    
    
    
3
    
    
    
    
4
    
    
    
    
5
    
    
    
    
6
    
    
    
    
7
    
    
    
    
8
    
    
    
    
9
   
   
   
   

• 在1-8步骤的任意一步系统宕机，事务未提交，该事务就不会对磁盘上的数据做任何影响。
• 如果在8-9之间宕机，恢复之后可以选择回滚，也可以选择继续完成事务提交，因为此时redo log已经持久化。
• 若在9之后系统宕机，内存映射中变更的数据还来不及刷回磁盘，那么系统恢复之后，可以根据redo log把数据刷回磁盘。

只有Buffer Pool的流程：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-tyHXqwlM-1680921939349)(C:/Users/dell/AppData/Roaming/Typora/typora-user-images/image-20230327193914352.png)]

redo + undo

在更新Buffer Pool中的数据之前，我们需要先将该数据事务开始之前的状态写入Undo Log中。假设更新到一半出错了，我们就可以通过Undo Log来回滚到事务开始前。

详细生成过程

对于InnoDB引擎来说，每个行记录除了记录本身的数据之外，还有几个隐藏的列:

• DB_ROW_ID：如果没有为表显式的定义主键，并且表中也没有定义唯一索引，那么InnoDB会自动为表添加一个row_id的隐藏列作为主键。
• DB_TRX_ID：每个事务都会分配一个事务ID，当对某条记录发生变更时，就会将这个事务的事务ID写入trx_id中。
• DB_ROLL_PTR：回滚指针，本质上就是指向undo log的指针。

执行INSERT时

begin;
INSERT INTO user (name) VALUES ("tom");

 
 
   
   
   
   

 
 
   
   
   
   

    
    
    
    
1
    
    
    
    
2
   
   
   
   

插入的数据都会生成一条insert undo log，并且数据的回滚指针会指向它。undo log会记录undo log 的序号、插入主键的列和值…，那么在进行rollback的时候，通过主键直接把对应的数据删除即可。

执行 UPDATE 时

对于更新的操作会产生update undo log，并且会分更新主键的和不更新主键的，假设现在执行:

UPDATE user SET name="Sun" WHERE id=1;

 
 
   
   
   
   

 
 
   
   
   
   

    
    
    
    
1
   
   
   
   

这时会把老的记录写入新的undo log，让回滚指针指向新的undo log，它的undo no是1，并且新的undo log会指向老的undo log (undo no=0)。

假设现在执行:

UPDATE user SET id=2 WHERE id=1 ;

 
 
   
   
   
   

 
 
   
   
   
   

    
    
    
    
1
   
   
   
   

**对于更新主键的操作，会先把原来的数据deletemark标识打开，这时并没有真正的删除数据，**真正的删除会交给清理线程去判断，然后在后面插入一条新的数据，新的数据也会产生undo log，并且undo log的序号会递增。

可以发现每次对数据的变更都会产生一个undo log，当一条记录被变更多次时，那么就会产生多条undo log，undo log记录的是变更前的日志，并且每个undo log的序号是递增的，那么当要回滚的时候，按照序号依次向前推，就可以找到我们的原始数据了。

undo log 如何回滚

以上面的例子来说，假设执行rollback，那么对应的流程应该是这样：

1. 通过undo no=3的日志把id=2的数据删除

2. 通过undo no=2的日志把id=1的数据的deletemark还原成0

3. 通过undo no=1的日志把id=1的数据的name还原成Tom

4. 通过undo no=0的日志把id=1的数据删除

undo log 的删除

• 针对于insert undo log

因为insert操作的记录，只对事务本身可见，对其他事务不可见。故该undo log可以在事务提交后直接删除，不需要进行purge操作。

• 针对于update undo log

该undo log可能需要提供MVCC机制，因此不能在事务提交时就进行删除。提交时放入undo log链表，等待purge线程进行最后的删除。

purge线程两个主要作用是:

清理undo页和清除page里面带有Delete_Bit标识的数据行。在InnoDB中，事务中的Delete操作实际上并不是真正的删除掉数据行，而是一种Delete Mark操作，在记录上标识Delete_Bit，而不删除记录。是一种"假删除";只是做了个标记，真正的删除工作需要后台purge线程去完成。

3. 小结

• redo log是物理日志，记录的是数据页的物理变化，undo log不是redo log的逆过程。
• undo log是逻辑日志，对事务回滚时，只是将数据库逻辑地恢复到原来的样子。

参考

https://www.bilibili.com/video/BV1iq4y1u7vj/?spm_id_from=333.337.search-card.all.click&vd_source=25b05e9bd8b4bdac16ca2f47bbeb7990