MySQL的undo log 与MVCC

文章目录

  • 概要
  • 一、undo日志
    • 1.undo日志的作用
    • 2.undo日志的格式
    • 3. 事务id(trx_id)
  • 二、MVCC
    • 1.版本链
    • 2.ReadView
    • 3.REPEATABLE READ —— 在第一次读取数据时生成一个ReadView
    • 4.快照读与当前读
  • 小结


概要

Undo Log:数据库事务开始之前,会将要修改的记录存放到 Undo 日志里,当事务回滚时或者数据库崩溃时,可以利用 Undo 日志,撤销未提交事务对数据库产生的影响。

MVCC(Multi Version Concurrency Control)被称为多版本控制,是指在数据库中为了实现高并发的数据访问,对数据进行多版本处理,并通过版本链保证事务能看到自己应该看到的数据版本。


一、undo日志

Undo:意为撤销或取消,以撤销操作为目的,返回指定某个状态的操作。
Undo Log:数据库事务开始之前,会将要修改的记录存放到 Undo 日志里,当事务回滚时或者数据库崩溃时,可以利用 Undo 日志,撤销未提交事务对数据库产生的影响。

1.undo日志的作用

undo日志只要有以下两个方面的作用:

  • 实现事务的原子性
    Undo Log 是为了实现事务的原子性而出现的产物。事务处理过程中,如果出现了错误或者用户执行了 ROLLBACK 语句,MySQL 可以利用 Undo Log 中的备份将数据恢复到事务开始之前的状态。
  • 实现多版本并发控制(MVCC)
    Undo Log 在 MySQL InnoDB 存储引擎中用来实现多版本并发控制。事务未提交之前,Undo Log保存了未提交之前的版本数据,Undo Log 中的数据可作为数据旧版本快照供其他并发事务进行快照读。

2.undo日志的格式

InnoDB行格式

我们平时是以记录为单位来向表中插入数据的,这些记录在磁盘上的存放方式也被称为行格式或者记录格式。

InnoDB一共有四种行格式:Compact、Redundant、Dynamic和Compressed行格式,行格式之间存在差异,但总体可以抽象成以下部分:
MySQL的undo log 与MVCC_第1张图片

聚簇索引的记录除了会保存完整的用户数据以外,而且还会自动添加名为trx_id、roll_pointer的隐藏列,如果用户没有在表中定义主键以及UNIQUE键,还会自动添加一个名为row_id的隐藏列。

trx_id:某个对这个聚簇索引记录做改动的语句所在的事务对应的事务id(此处的改动可以是INSERT、DELETE、UPDATE操作)
roll_pointer:每次对某条聚簇索引记录进行改动时,都会把旧的版本写入到undo日志中,然后这个隐藏列就相当于一个指针,可以通过它来找到该记录修改前的信息

undo日志格式

为了实现事务的原子性,InnoDB存储引擎在实际进行增、删、改一条记录时,都需要先把对应的undo日志记下来。一般每对一条记录做一次改动,就对应着一条undo日志。不同的操作(insert,delete,update)对应的undo日志有所差异,他们对应的undo日志格式展示如下。这里不会展开对每种日志字段进行说明,主要还是总结他们的差异和作用,以及跟行数据之间是如何通过roll_pointer属性进行联系。

insert操作的undo日志

MySQL的undo log 与MVCC_第2张图片
这里需要注意的是,insert操作对应的undo日志没有roll_pointer属性的,因为该记录并没有更早的版本。

插入一条数据时,行记录跟undo日志的关系如下:
MySQL的undo log 与MVCC_第3张图片

delete操作的undo日志

MySQL的undo log 与MVCC_第4张图片
重点关注:

  1. delete操作的undo日志有roll_pointer属性
  2. delete操作是分为两个阶段来操作的:delete mark 阶段和 purge阶段,在delete mark阶段并不会真正地将数据从页面中清除,而是设置头信息为delete标识,在这个阶段同时将数据加入到版本链中。
    MySQL的undo log 与MVCC_第5张图片

update操作的undo日志

MySQL的undo log 与MVCC_第6张图片
更新时,有以下几种情况:
MySQL的undo log 与MVCC_第7张图片
MySQL的undo log 与MVCC_第8张图片

3. 事务id(trx_id)

一个事务可以是一个只读事务,或者是一个读写事务:

  1. 可以通过START TRANSACTION READ ONLY语句开启一个只读事务。
    在只读事务中不可以对普通的表(其他事务也能访问到的表)进行增、删、改操作,但可以对临时表做增、删、改操作。
  2. 可以通过START TRANSACTION READ WRITE语句开启一个读写事务,或者使BEGIN、START TRANSACTION语句开启的事务默认也算是读写事务。
    在读写事务中可以对表执行增删改查操作。如果某个事务执行过程中对某个表执行了增、删、改操作,那么InnoDB存储引擎就会给它分配一个独一无二的事务id

常见的场景:
MySQL的undo log 与MVCC_第9张图片

上图操作中,虽然已经开启了一个事务,并且也对某张表进行了查询操作,但是因为没有对表进行增删改操作,这个时候,InnoDB引擎是不会分配事务id的。

二、MVCC

MVCC(Multi Version Concurrency Control)被称为多版本控制,是指在数据库中为了实现高并发的数据访问,对数据进行多版本处理,并通过版本链保证事务能看到自己应该看到的数据版本。
多版本控制很巧妙地将稀缺资源的独占互斥转换为并发,大大提高了数据库的吞吐量及读写性能。
如何生成的多版本?每次事务修改操作之前,都会在Undo日志中记录修改之前的数据状态和事务号,该备份记录可以用于其他事务的读取,也可以进行必要时的数据回滚。

MVCC最大的好处是读不加锁,读写不冲突。在读多写少的系统应用中,读写不冲突是非常重要的,极大的提升系统的并发性能,这也是为什么现阶段几乎所有的关系型数据库都支持 MVCC 的原因,不过目前MVCC只在Read CommitedRepeatable Read 两种隔离级别下工作。

1.版本链

创建一张表,并向数据表中添加一条记录

CREATE TABLE `user_mvcc` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `name` varchar(20) NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB;

insert into user_mvcc (name) VALUES('Tom');
# 查询
mysql> select * from user_mvcc where id = 6;
+----+----------+
| id | name |
+----+----------+
|  6 | Tom      |
+----+----------+
1 row in set (0.11 sec)

之后两个事务id分别为100、200的事务对id=6这条记录进行UPDATE操作,操作流程如下:
MySQL的undo log 与MVCC_第10张图片

每次对记录进行改动,都会记录一条undo日志,每条undo日志也都有一个roll_pointer属性(INSERT操作对应的undo日志没有该属性,因为该记录并没有更早的版本),可以将这些undo日志都连起来,串成一个链表:
MySQL的undo log 与MVCC_第11张图片

对该记录每次更新后,都会将旧值放到一条undo日志中,就算是该记录的一个旧版本,随着更新次数的增多,所有的版本都会被roll_pointer属性连接成一个链表,我们把这个链表称之为版本链版本链的头节点就是当前记录最新的值。另外,每个版本中还包含生成该版本时对应的事务id

2.ReadView

使用READ COMMITTED或者REPEATABLE READ隔离级别,在当前事务中,必须保证以下两点:

  1. 能读到已经提交了的事务修改过的记录
  2. 不能读取到另一个事务已经修改的,但是尚未提交的记录。这个时候就要继续往上找该条记录的上一个版本,在依照一定的规则判断该版本的记录是否可见。这个规则,下面进行介绍。

所以核心问题就是:需要判断一下版本链中的哪个版本是当前事务可见的。为此,设计InnoDB的大佬提出了一个ReadView的概念,这个ReadView中主要包含4个比较重要的内容:

  • m_ids:表示在生成ReadView时当前系统中活跃的读写事务的事务id列表

  • min_trx_id:表示在生成ReadView时当前系统中活跃的读写事务中最小的事务id,也就是m_ids中的最小值。

  • max_trx_id:表示生成ReadView时系统中应该分配给下一个事务的id值
    注意max_trx_id并不是m_ids中的最大值,事务id是递增分配的。比方说现在有id为1,2,3这三个事务,之后id为3的事务提交了。那么一个新的读事务在生成ReadView时,m_ids就包括1和2,min_trx_id的值就是1,max_trx_id的值就是4

  • creator_trx_id:表示生成该ReadView的事务的事务id
    只有在对表中的记录做改动时(执行INSERT、DELETE、UPDATE这些语句时)才会为事务分配事务id,否则在一个只读事务中的事务id值都默认为0。

数据版本的可见性规则,就是基于数据的 row trx_id 和这个一致性视图的对比结果得到的。

MySQL的undo log 与MVCC_第12张图片

有了这个ReadView,这样在访问某条记录时,只需要按照下面的步骤判断记录的某个版本是否可见:

  • 如果被访问版本的trx_id属性值与ReadView中的creator_trx_id值相同,意味着当前事务在访问它自己修改过的记录,所以该版本可以被当前事务访问。
  • 如果被访问版本的trx_id属性值小于ReadView中的min_trx_id值,表明生成该版本的事务在当前事务生成ReadView前已经提交,所以该版本可以被当前事务访问。
  • 如果被访问版本的trx_id属性值大于ReadView中的max_trx_id值,表明生成该版本的事务在当前事务生成ReadView后才开启,所以该版本不可以被当前事务访问。
  • 如果被访问版本的trx_id属性值在ReadView的min_trx_idmax_trx_id之间,那就需要判断一下trx_id属性值是不是在m_ids列表中,如果在,说明创建ReadView时生成该版本的事务还是活跃的,该版本不可以被访问;如果不在,说明创建ReadView时生成该版本的事务已经被提交,该版本可以被访问。

如果某个版本的数据对当前事务不可见的话,那就顺着版本链找到下一个版本的数据,继续按照上面的步骤判断可见性,依此类推,直到版本链中的最后一个版本。如果最后一个版本也不可见的话,那么就意味着该条记录对该事务完全不可见,查询结果就不包含该记录。

下面以REPEATABLE READ隔离级别下的MVCC演示说明。

3.REPEATABLE READ —— 在第一次读取数据时生成一个ReadView

还是以user_mvcc中id为6的数据举例:

mysql> select * from user_mvcc where id = 6;
+----+----------+
| id | name |
+----+----------+
|  6 | lisi     |
+----+----------+
1 row in set (0.08 sec)

有3个事务的执行顺序如下
MySQL的undo log 与MVCC_第13张图片
下面通过以上的规则,说明为什么trx300两次查询的结果是lisi.

在trx100执行时间点5完成后,user_mvcc表中id=6的记录得到的版本链如下:

MySQL的undo log 与MVCC_第14张图片
在时刻6,事务trx200执行更新其他表的操作,主要是为了分配事务id

时刻7查询1的分析如下:

  • 在执行SELECT语句时会先生成一个ReadView,ReadView的m_ids列表的内容就是[100, 200]min_trx_id为100,max_trx_id为201,creator_trx_id为0。
  • 然后从版本链中挑选可见的记录,从图中可以看出,最新版本的列name的内容是’jack’,该版本的trx_id值为100,在m_ids列表内,所以不符合可见性要求,根据roll_pointer跳到下一个版本。
  • 下一个版本的列name的内容是’Ally’,该版本的trx_id值也为100,也在m_ids列表内,所以也不符合要求,继续跳到下一个版本。
  • 下一个版本的列name的内容是’lisi’,该版本的trx_id值为80,小于ReadView中的min_trx_id值100,所以这个版本是符合要求的,最后返回给用户的版本就是这条列name为’lisi’的记录。

之后trx100事务提交,trx200执行更新user_mvcc表的id=6的记录,此时该条记录的版本链如下:
MySQL的undo log 与MVCC_第15张图片
时刻10查询2的分析如下:

  • 因为当前事务的隔离级别为REPEATABLE READ,而之前在执行第一次查询时已经生成过ReadView了,所以此时直接复用之前的ReadView,之前的ReadView的m_ids列表的内容就是[100, 200]min_trx_id为100,max_trx_id为201,creator_trx_id为0。
  • 然后从版本链中挑选可见的记录,从图中可以看出,最新版本的列name的内容是’leilei’,该版本的trx_id值为200,在m_ids列表内,所以不符合可见性要求,根据roll_pointer跳到下一个版本。
  • 下一个版本的列name的内容是’jack’,该版本的trx_id值为100,也在m_ids列表内,所以也不符合要求,继续跳到下一个版本。
  • 下一个版本的列name的内容是’Ally’,该版本的trx_id值为100,也在m_ids列表内,不符合,继续跳到下一个版本。
  • 下一个版本的列name的内容是’lisi’,该版本的trx_id值为80,小于ReadView中的min_trx_id值100,所以这个版本是符合要求。

也就是说两次SELECT查询得到的结果是相同,都是’lisi’,这就是可重复读的含义。

READ COMMITTD、REPEATABLE READ这两个隔离级别的一个很大不同就是:生成ReadView的时机不同,READ COMMITTD在每一次进行普通SELECT操作前都会生成一个ReadView,而REPEATABLE READ只在第一次进行普通SELECT操作前生成一个ReadView,之后的查询操作都重复使用这个ReadView。

4.快照读与当前读

有以下数据:

mysql> select * from t where id =1;
+----+---+
| id | c |
+----+---+
|  1 | 1 |
+----+---+
1 row in set (0.09 sec)

现在有以下操作场景:

MySQL的undo log 与MVCC_第16张图片

那么此时,图中的SELECT1,SELECT2,SELECT3查询得到的c的值分别是多少?

根据前面的分析,很容易得到SELECT1,SELECT2得到c的值是1,而在SELECT3中,按照前面的分析应该得到c的值为2,但实际查询得到的结果是c = 3,那为什么会出现这种结果呢?

在 MVCC 并发控制中,读操作可以分为两类: 快照读(Snapshot Read)与当前读 (Current Read)

  • 快照读:读取的是记录的快照版本(有可能是历史版本),不用加锁。我们平时的select操作就是快照读
  • 当前读:读取的是记录的最新版本,并且当前读返回的记录,都会加锁,保证其他事务不会再并发修改这条记录。
    开启当前读的方式有:select… for update 或lock in share mode
    平时的insert/delete/update操作也是用的当前读的方式

所以图上的UPDATE2场景就是用到了当前读:更新数据都是先读后写;

UPDATE2更新之前,事务trx300执行了更新,此次该条数据的版本链中最新的数据为(1,2),当UPDATE2再进行更新时,因为是当前读,所以会拿到最新的值2进行操作,当UPDATE2执行完后,版本链中该条数据的c值就变成了3,所以在SELECT3中,查看到的c的值为3.

小结

所谓的MVCC(Multi-Version Concurrency Control ,多版本并发控制)指的就是在使用READ COMMITTD、REPEATABLE READ这两种隔离级别的事务在执行普通的SEELCT操作时访问记录的版本链的过程,这样子可以使不同事务的读-写、写-读操作并发执行,从而提升系统性能。MVCC的实现是通过undo日志来完成的。

InnoDB 的行数据有多个版本,每个数据版本有自己的 row trx_id,每个事务或者语句有自己的一致性视图。普通查询语句是一致性读(快照读),一致性读会根据 row trx_id 和一致性视图确定数据版本的可见性。

  • REPEATABLE READ:只在第一次进行普通SELECT操作前生成一个ReadView,之后的查询操作都重复使用这个ReadView
  • READ COMMITTD:每一次进行普通SELECT操作前都会生成一个ReadView

更新数据操作都是先读后写的,读的都是版本链中最新的值,称为“当前读”(current read)

你可能感兴趣的:(MySQL,mysql,MVCC,快照读与当前读,undo日志)