文章目录

一、引入 undo log

一般数据库引擎默认工作在事务的中间两个隔离级别：

  1. TRANSACTION_READ_COMMITTED，已提交读，oracle默认工作级别。不允许读取未commit的数据，这个级别仍然允许不可重复读和虚读产生。
  2. TRANSACTION_REPEATABLE_READ，可重复读，MySQL默认工作级别。保证事务再次读取是依然得到相同的数据，部分解决了虚读，但虚读是仍然会出现的

MySQL 回滚日志 undo log_mvc


注：

  • 事务隔离级别越高，为避免冲突所花费的性能也就越多
  • 在可重复读级别，实际上可以解决部分的虚读问题，但是不能防止update更新产生的虚读问题，要禁止虚读产生，还是需要设置串行化隔离级别

InnoDB的已提交读和可重复读的底层实现原理：MVCC（多版本并发控制），MVCC提供了一种并发的读取方式，即快照读 ，同一份数据会有多个版本

InnoDB提供了2种读取操作：锁定读和非锁定读

  • 锁定读就是读取的时候加锁（S或X）
  • 非锁定读就是读取的时候没有加锁，指的就是MVCC提供的快照读—>快照读依赖的是底层的undo log回滚日志

ACD特性用事务日志实现，I 特性用共享锁、排它锁、MVCC 实现。事务日志分为undo log（回滚日志） 和 redo log（重做日志）

二、undo log

1. undo log的概念

undo log和redo log统称事务日志，不同于binlog是MySQL Server层的日志，这两个属于存储引擎层的日志

  • redo log：重做日志，记录事务操作的变化，确保事务的持久性。redo log在事务开始时就开始记录，不管事务是否commit都会记录。出现异常时（如数据持久化过程断电），重启后InnoDB会使用redo log恢复到断电前的状态，保证数据的完整性
  • undo log：回滚日志，保存了事务发生之前的数据的一个版本，用于事务的回滚操作，同时也是实现多版本并发控制（MVCC）下读操作（快照读）的关键技术

2. undo log的作用

undo log回滚日志的主要作用：

  • 事务发生错误时回滚rollback ，数据更新之前，会把原始数据保存在回滚日志中，保证事务出错回滚或者我们手动回滚的时候，能够在回滚日志中找到最初的数据
  • 提供了MVCC的非锁定读（快照读），依赖undo log实现

3. undo log的数据结构

MySQL 回滚日志 undo log_mvc_02


在MVCC下，针对表的所有记录，除了我们自行设定的字段book_id、book_name、auther

MySQL 回滚日志 undo log_mvc_03


还会添加几个字段

MySQL 回滚日志 undo log_数据库_04

  • DB_ROW_ID：MVCC的关系不大，这个是我们创建表的时候，如果没有加PRIMARY KEY，那么InnoDB就自动生成主键列id（DB_ROW_ID），通过这个id作为主键创建索引树，在B+树的叶子节点上存放数据。由于InnoDB的数据和索引是存放在一起的，如果我们没有设置主键，InnoDB会自动生成主键
  • DB_TRX_ID：事务ID，我们每打开一个客户端session，输入begin，向服务器请求开启一个事务。事务开启请求发到MySQL server上，MySQL server为每个事务都会分配一个全局的，不冲突的事务ID（InnoDB存储引擎分配的，因为它才支持事务）。当某个事务修改数据时，DB_TRX_ID放的就是该事务的ID，同一个事务无论怎么更改数据，这个事务ID都不会改变
  • DB_ROLL_PTR：回滚指针，我们看到，存放的是地址，这个地址表示的是一个数据的内存的位置，看起来是一个链表，上图中的这个橙色表是最后的成品，那么这个表是怎么变来的呢？

最初的时候表是这样的：

MySQL 回滚日志 undo log_数据库_05

现在有一个ID为1001的事务来更改这条数据，这个事务把book_name改成了“笑傲江湖（吕颂贤）”

此时数据涉及到修改了，修改的数据存放在当前这个表中，那修改之前的数据怎么办？防止事务回滚恢复修改前的状态，需要将最初的数据存放在undo log中！

现在undo log的数据结构如下：

MySQL 回滚日志 undo log_数据_06

现在有一个ID为1002的事务来更改这条数据，这个事务把book_name改成了“笑傲江湖（李亚鹏）”

现在undo log的数据结构如下：

MySQL 回滚日志 undo log_回滚_07

MVCC会给我们创建的表增加2个列，一个是事务ID，一个是指向修改前的数据的指针，修改之前的数据都是放在undo log回滚日志当中。对于每个版本的数据，是哪个事务改的DB_TRX_ID就写哪个事务ID，DB_ROLL_PTR指针把当前数据和旧数据串成1个链表。从当前行的DB_ROLL_PTR可以访问到旧数据，进行回滚就很简单了

三、undo log举例

原始的user表如下：

MySQL 回滚日志 undo log_数据_08

MVCC机制会对这张表增加2列，修改当前数据的事务ID（DB_TRX_ID）和指向undo log的指针（DB_ROLL_PTR）

我们把id=7的age改为16，如下图所示：

MySQL 回滚日志 undo log_数据_09


原来(id=7,age=15)这个版本的数据放到了undo log中这是我们再增加了1行新数据，由于新增的数据没有对应的老版本，所以undo log中对应为NULL，如下图所示：

MySQL 回滚日志 undo log_数据_10


回滚的时候发现是NULL，就知道是insert增加的数据，直接执行insert的反操作delete就可以了

同样的，如果我们这时要修改刚刚insert的数据，将id=23的age改成23

MySQL 回滚日志 undo log_mvc_11


在已提交读和可重复读隔离级别下，当我们去读数据的时候，可不是像串行化一样通过SX锁或间隙锁实现，而是纯粹通过MVCC的快照读实现的