0


一文带你了解MySQL之事务隔离级别和MVCC

目录

一、数据准备

为了我们学习的顺利进行,我们这边创建一张

hero

CREATETABLE hero(
    number INTPRIMARYKEY,
    name VARCHAR(4),
    country VARCHAR(2));

这里需要注意的是,我们的

hero

表的主键是

number

,而不是

id

,主要是后边要用到的

事务id

做一下区别,然后我们给这个表里插入一条数据

mysql>INSERTINTO hero VALUES(1,'张角','东汉');
Query OK,1row affected (0.01 sec

现在我们表里的数据就是这样:

mysql>SELECT*FROM hero;+--------+--------+---------+| number | name   | country |+--------+--------+---------+|1| 张角   | 东汉    |+--------+--------+---------+1rowinset(0.00 sec)

二、事务隔离级别

我们知道

MySQL

CS

架构的软件,若干个客户端与服务器连接上之后,就可以称之为一个

会话

Session

)。每个客户端都可以在自己的会话中向服务器发出请求语句,一个请求语句可能是某个事务的一部分,也就是对于服务器来说可能同时处理多个事务。在事务简介的章节中我们说过事务有一个称之为

隔离性

的特性,理论上在某个事务对某个数据进行访问时,其他事务应该进行排队,当该事务提交之后,其他事务才可以继续访问这个数据。但是这样子的话对性能影响太大,我们既想保持事务的

隔离性

,又想让服务器在处理访问同一数据的多个事务时性能尽量高些,鱼和熊掌不可得兼,舍

一部分隔离性而取性能者也

2.1 事务并发执行遇到的问题

怎么个舍弃法呢?我们先得看一下访问相同数据的事务在不保证

串行执行

(也就是执行完一个再执行另一个)的情况下可能会出现哪些问题:

**

脏写(Dirty Write):

** 如果一个事务修改了另一个

未提交事务修改过的数据

,那就意味着发生了

脏写

,示意图如下:
Session ASession B1BEGIN;2BEGIN;3UPDATE hero SET name = ‘赵云’ WHERE number = 1;4UPDATE hero SET name = ‘法正’ WHERE number = 1;5COMMIT;6ROLLBACK;
如上表,

Session A

Session B

各开启了一个事务,

Session B

中的事务先将

number

列为

1

的记录的

name

列更新为

'赵云'

,然后

Session A

中的事务接着又把这条

number

列为

1

的记录的

name

列更新为

法正

。如果之后

Session B

中的事务进行了回滚,那么

Session A

中的更新也将不复存在,这种现象就称之为

脏写

。这时

Session A

中的事务就很懵逼,我明明把数据更新了,最后也提交事务了,怎么到最后说自己啥也没干呢?

**

脏读(Dirty Read)

** :如果一个事务读到了另一个未提交事务修改过的数据,那就意味着发生了脏读,示意图如下:
Session ASession B1BEGIN;2BEGIN;3UPDATE hero SET name = ‘赵云’ WHERE number = 1;4SELECT * FROM hero WHERE number = 1;(此时读到的name列的值为‘赵云’,味的发生了

脏读

)5COMMIT;6ROLLBACK;
如上表,

Session A

Session B

各开启了一个事务,

Session B

中的事务先将

number

列为

1

的记录的

name

列更新为

'赵云'

,然后

Session A

中的事务再去查询这条

number

1

的记录,如果读到列

name

的值为

'赵云'

,而

Session B

中的事务稍后进行了

回滚

,那么

Session A

中的事务相当于读到了一个

不存在的数据

,这种现象就称之为

脏读

**

不可重复读(Non-Repeatable Read):

** 如果一个事务只能读到另一个已经提交的事务修改过的数据,并且其他事务每对该数据进行一次修改并提交后,该事务都能查询得到最新值,那就意味着发生了

不可重复读

,示意图如下:
Session ASession B1BEGIN;2SELECT * FROM hero WHERE number = 1;(此时读到的name列的值为‘张角’)3UPDATE hero SET name = ‘赵云’ WHERE number = 1;4SELECT * FROM hero WHERE number = 1;(此时读到的name列的值为‘赵云’,意味的发生了不可重复读)5UPDATE hero SET name = ‘法正’ WHERE number = 1;6SELECT * FROM hero WHERE number = 1;(此时读到的name列的值为‘法正’,意味的发生了不可重复读)
如上表,我们在

Session B

中提交了几个

隐式事务

(意味着语句结束事务就提交了),这些事务都修改了

number

列为

1

的记录的列

name

的值,每次事务提交之后,如果

Session A

中的事务都可以查看到最新的值,这种现象也被称之为

不可重复读

**

幻读(Phantom):

** 如果一个事务先根据某些条件查询出一些记录,之后另一个事务又向表中插入了符合这些条件的记录,原先的事务再次按照该条件查询时,能把另一个事务插入的记录也读出来,那就意味着发生了

幻读

,示意图如下:
Session ASession B1BEGIN;2SELECT * FROM hero WHERE number = 1;(此时读到的name列的值为‘张角’)3INSERT INTO hero VALUES(1,‘许诸’,‘魏国’);4SELECT * FROM hero WHERE number = 1;(此时读到的name列的值为‘张角’、‘许诸’,意味的发生了幻读)
如上表,

Session A

中的事务先根据条件

number > 0

这个条件查询表

hero

,得到了

name

列值为

'张角'

的记录;之后

Session B

中提交了一个

隐式事务

,该事务向表

hero

中插入了一条新记录;之后

Session A

中的事务再根据相同的条件

number > 0

查询表

hero

,得到的结果集中包含

Session B

中的事务新插入的那条记录,这种现象也被称之为

幻读

**

Q1

:** 如果

Session B

中是删除了一些符合

number > 0

的记录而不是插入新记录,那

Session A

中之后再根据

number > 0

的条件读取的记录变少了,这种现象算不算幻读呢?

**

W1

:** 明确说一下,这种现象不属于幻读,幻读强调的是一个事务按照某个相同条件多次读取记录时,后读取时读到了之前没有读到的记录。

**

小提士:

**
那对于先前已经读到的记录,之后又读取不到这种情况,算啥呢?其实这相当于对每一条记录都发生了不可重复读的现象。幻读只是重点强调了读取到了之前读取没有获取到的记录。

2.2 SQL标准中的四种隔离级别

我们上边介绍了几种并发事务执行过程中可能遇到的一些问题,这些问题也有轻重缓急之分,我们给这些问题按照严重性来排一下序:

脏写 > 脏读 > 不可重复读 > 幻读

我们上边所说的

舍弃一部分隔离性来换取一部分性能

在这里就体现在:设立一些隔离级别,隔离级别越低,越严重的问题就越可能发生。于是制定了一个所谓的

SQL标准

,在标准中设立了4个

隔离级别

  • READ UNCOMMITTED:未提交读
  • READ COMMITTED:已提交读
  • REPEATABLE READ:可重复读
  • SERIALIZABLE:可串行化
SQL标准

中规定,针对不同的

隔离级别

,并发事务可以发生不同严重程度的问题,具体情况如下:
隔离级别脏读不可重复读幻读

READ UNCOMMITTED

PossiblePossiblePossible

READ COMMITTED

Not PossiblePossiblePossible

REPEATABLE READ

Not PossibleNot PossiblePossible

SERIALIZABLE

Not PossibleNot PossibleNot Possible
也就是说:

  • READ UNCOMMITTED隔离级别下,可能发生脏读、不可重复读和幻读问题。
  • READ COMMITTED隔离级别下,可能发生不可重复读和幻读问题,但是不可以发生脏读问题。
  • REPEATABLE READ隔离级别下,可能发生幻读问题,但是不可以发生脏读和不可重复读的问题。
  • SERIALIZABLE隔离级别下,各种问题都不可以发生。

**

Q2:

** 脏写是怎么回事儿?怎么里边都没写呢?
**

W2:

** 这是因为脏写这个问题太严重了,不论是哪种隔离级别,都不允许脏写的情况发生。

2.3 MySQL中支持的四种隔离级别

不同的数据库厂商对

SQL标准

中规定的四种隔离级别支持不一样,比方说

Oracle

就只支持

READ COMMITTED

SERIALIZABLE

隔离级别。

MySQL

虽然支持4种隔离级别,但与

SQL标准

中所规定的各级隔离级别允许发生的问题却有些出入,

MySQL

REPEATABLE READ

隔离级别下,是可以

禁止幻读问题的发生的

MySQL

的默认隔离级别为

REPEATABLE READ

,我们可以手动修改一下事务的隔离级别。

如何设置事务的隔离级别

我们可以通过下边的语句修改事务的隔离级别:

SET[GLOBAL|SESSION|PERSIST]TRANSACTIONISOLATIONLEVELlevel;

其中的

level

可选值有

4

个:

level:{
     REPEATABLE READ
   | READ COMMITTED
   | READ UNCOMMITTED
   | SERIALIZABLE
}

设置事务的隔离级别的语句中,在

SET

关键字后可以放置

GLOBAL

关键字、

SESSION

关键字、

PERSIST

关键字或者什么都不放,这样会对不同范围的事务产生不同的影响,具体如下:

  • 使用GLOBAL关键字(在全局范围影响):比如:SET GLOBAL TRANSACTION ISOLATION LEVEL SERIALIZABLE;则:- 只对执行完该语句之后产生的会话起作用。- 当前已经存在的会话无效- 重启之后会恢复到默认值
  • 使用SESSION关键字(在会话范围影响):比如:SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE;则:- 对当前会话的所有后续的事务有效- 该语句可以在已经开启的事务中间执行,但不会影响当前正在执行的事务- 如果在事务之间执行,则对后续的事务有效- 重启之后会恢复到默认值
  • 使用PERSIST关键字(使全局系统变量变为永久性):比如:SET PERSIST TRANSACTION ISOLATION LEVEL SERIALIZABLE; 则:- 只对执行完该语句之后产生的会话起作用- 当前已经存在的会话无效- 重启之后不会恢复到默认值> **> > 小提示:> > **> 在5.7版本以前在修改全局变量时候,并不会影响到配置文件,重启之后就会恢复到默认值,MySQL8可以使用> > PERSIST> > 使全局系统变量变为永久性
  • 上述三个关键字都不用(只对执行语句后的下一个事务产生影响):比如:SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;则:- 只对当前会话中下一个即将开启的事务有效。- 下一个事务执行完后,后续事务将恢复到之前的隔离级别。- 该语句不能在已经开启的事务中间执行,会报错的

想要查看当前会话默认的隔离级别可以通过查看系统变量

transaction_isolation

的值来确定:

mysql>SHOW VARIABLES LIKE'transaction_isolation';+-----------------------+--------------+| Variable_name         |Value|+-----------------------+--------------+| transaction_isolation |SERIALIZABLE|+-----------------------+--------------+1rowinset(0.01 sec)

或者使用更简便的写法:

mysql> SELECT @@transaction_isolation;
+-------------------------+
| @@transaction_isolation |
+-------------------------+
| SERIALIZABLE            |
+-------------------------+
1 row in set (0.00 sec)

三、MVCC

3.1 版本链

我们前边说过,对于使用

InnoDB

存储引擎的表来说,它的聚簇索引记录中都包含两个必要的隐藏列(

row_id

并不是必要的,我们创建的表中有

主键

或者

非NULL的UNIQUE

键时都不会包含

row_id

列):

  • trx_id:每次一个事务对某条聚簇索引记录进行改动时,都会把该事务的事务id赋值给trx_id隐藏列。
  • roll_pointer:每次对某条聚簇索引记录进行改动时,都会把旧的版本写入到undo日志中,然后这个隐藏列就相当于一个指针,可以通过它来找到该记录修改前的信息

比如我们的表

hero

现在只包含一条记录:

mysql>SELECT*FROM hero;+--------+--------+---------+| number | name   | country |+--------+--------+---------+|1| 张角   | 东汉    |+--------+--------+---------+1rowinset(0.00 sec)

假设插入该记录的

事务id

为80,那么此刻该条记录的示意图如下所示:

在这里插入图片描述

**

小提示:

**
实际上insert undo只在事务回滚时起作用,当事务提交后,该类型的undo日志就没用了,它占用的Undo Log Segment也会被系统回收(也就是该undo日志占用的Undo页面链表要么被重用,要么被释放)。虽然真正的insert undo日志占用的存储空间被释放了,但是roll_pointer的值并不会被清除,roll_pointer属性占用7个字节,第一个比特位就标记着它指向的undo日志的类型,如果该比特位的值为1时,就代表着它指向的undo日志类型为insert undo。所以我们之后在画图时都会把insert undo给去掉,大家留意一下就好了。

假设之后两个事务

id

分别为

100

200

的事务对这条记录进行

UPDATE

操作,操作流程如下:
trx 100trx 2001BEGIN;2BEGIN;3UPDATE hero SET name = ‘赵云’ WHERE number = 1;4UPDATE hero SET name = ‘法正’ WHERE number = 1;5COMMIT;6UPDATE hero SET name = ‘孙尚香’ WHERE number = 1;7UPDATE hero SET name = ‘妲己’ WHERE number = 1;8COMMIT;

**

小提示:

**
能不能在两个事务中交叉更新同一条记录呢?哈哈,这不就是一个事务修改了另一个未提交事务修改过的数据,沦为了脏写了么?InnoDB使用锁来保证不会有脏写情况的发生,也就是在第一个事务更新了某条记录后,就会给这条记录加锁,另一个事务再次更新时就需要等待第一个事务提交了,把锁释放之后才可以继续更新。关于锁的更多细节我们后续的文章中再进行学习~

每次对记录进行更新,都会记录一条

undo

日志,每条

undo

日志也都有一个

roll_pointer

属性(INSERT操作对应的undo日志没有该属性,因为该记录并没有更早的版本),可以将这些

undo

日志都连起来,串成一个链表,所以现在的情况就像下图一样:

在这里插入图片描述
对该记录每次更新后,都会将旧值放到一条

undo

日志中,就算是该记录的一个旧版本,随着更新次数的增多,所有的版本都会被

roll_pointer

属性连接成一个链表,我们把这个链表称之为

版本链

,版本链的头节点就是当前记录最新的值。另外,每个版本中还包含生成该版本时对应的

事务id

,这个信息很重要,我们稍后就会用到。

3.2 ReadView

对于使用

READ UNCOMMITTED

隔离级别的事务来说,由于可以读到未提交事务修改过的记录,所以直接读取记录的最新版本就好了;对于使用

SERIALIZABLE

隔离级别的事务来说,

InnoDB

的规定使用

加锁的方式来访问记录

(加锁是啥我们后续文章中说哈);对于使用

READ COMMITTED

REPEATABLE READ

隔离级别的事务来说,都必须保证读到已经提交了的事务修改过的记录,也就是说假如另一个事务已经修改了记录但是尚未提交,是不能直接读取最新版本的记录的,核心问题就是:需要判断一下版本链中的哪个版本是当前事务可见的。为此,

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。

有了这个

ReadView

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

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

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

MySQL

中,

READ COMMITTED

REPEATABLE READ

隔离级别的的一个非常大的区别就是它们生成

ReadView

的时机不同。我们还是以表

hero

为例来,假设现在表

hero

中只有一条由事务

id

80

的事务插入的一条记录:

mysql>SELECT*FROM hero;+--------+--------+---------+| number | name   | country |+--------+--------+---------+|1| 张角   | 东汉    |+--------+--------+---------+1rowinset(0.00 sec)

接下来看一下

READ COMMITTED

REPEATABLE READ

所谓的生成

ReadView

的时机不同到底不同在哪里

3.2.1 READ COMMITTED

对于使用

REPEATABLE COMMITTED

隔离级别的事务来说,每次读取数据前都生成一个

ReadView

。比方说现在系统里有两个事务

id

分别为

100

200

的事务在执行:

# Transaction 100BEGIN;UPDATE hero SET name ='赵云'WHERE number =1;UPDATE hero SET name ='法正'WHERE number =1;
# Transaction 200BEGIN;# 更新了一些别的表的记录...

**

小提示:

**
再次强调一遍,事务执行过程中,只有在第一次真正修改记录时(比如使用INSERT、DELETE、UPDATE语句),才会被分配一个单独的事务id,这个事务id是递增的。所以我们才在Transaction 200中更新一些别的表的记录,目的是让它分配事务id。

此刻,表

hero

number

1

的记录得到的版本链表如下所示:

在这里插入图片描述
假设现在有一个使用

READ COMMITTED

隔离级别的事务开始执行:

# 使用READ COMMITTED隔离级别的事务BEGIN;# SELECT1:Transaction 100、200未提交SELECT*FROM hero WHERE number =1;# 得到的列name的值为'张角'

这个

SELECT1

的执行过程如下:

  • 在执行SELECT语句时会先生成一个ReadViewReadViewm_ids列表的内容就是[100, 200]min_trx_id100max_trx_id201creator_trx_id0
  • 然后从版本链中挑选可见的记录,从图中可以看出,最新版本的列name的内容是'法正',该版本的trx_id值为100,在m_ids列表内,所以不符合可见性要求,根据roll_pointer跳到下一个版本。
  • 下一个版本的列name的内容是'赵云',该版本的trx_id值也为100,也在m_ids列表内,所以也不符合要求,继续跳到下一个版本。下一个版本的列name的内容是'张角',该版本的trx_id值为80,小于ReadView中的min_trx_id100,所以这个版本是符合要求的,最后返回给用户的版本就是这条列name'张角'的记录。
# Transaction 100BEGIN;UPDATE hero SET name ='赵云'WHERE number =1;UPDATE hero SET name ='法正'WHERE number =1;COMMIT;

然后再到

事务id

200

的事务中更新一下表

hero

number

为1的记录:

# Transaction 200BEGIN;# 更新了一些别的表的记录UPDATE hero SET name ='孙尚香'WHERE number =1;UPDATE hero SET name ='妲己'WHERE number =1;

此刻,表

hero

number

1

的记录的版本链就长这样:

在这里插入图片描述
然后再到刚才使用

READ COMMITTED

隔离级别的事务中继续查找这个

number

1

的记录,如下:

# 使用READ COMMITTED隔离级别的事务BEGIN;# SELECT1:Transaction 100、200均未提交SELECT*FROM hero WHERE number =1;# 得到的列name的值为'张角'# SELECT2:Transaction 100提交,Transaction 200未提交SELECT*FROM hero WHERE number =1;# 得到的列name的值为'法正'

这个SELECT2的执行过程如下:

  • 在执行SELECT语句时会又会单独生成一个ReadView,该ReadViewm_ids列表的内容就是[200]事务id100的那个事务已经提交了,所以再次生成快照时就没有它了),min_trx_id200max_trx_id201creator_trx_id0
  • 然后从版本链中挑选可见的记录,从图中可以看出,最新版本的列name的内容是'妲己',该版本的trx_id值为200,在m_ids列表内,所以不符合可见性要求,根据roll_pointer跳到下一个版本。
  • 下一个版本的列name的内容是'孙尚香',该版本的trx_id值为200,也在m_ids列表内,所以也不符合要求,继续跳到下一个版本。
  • 下一个版本的列name的内容是'法正',该版本的trx_id值为100,小于ReadView中的min_trx_id200,所以这个版本是符合要求的,最后返回给用户的版本就是这条列name'法正'的记录。

以此类推,如果之后

事务id

200

的记录也提交了,再次在使用

READ COMMITTED

隔离级别的事务中查询表

hero

number

值为

1

的记录时,得到的结果就是

'妲己'

了,具体流程我们就不分析了。总结一下就是:使用

READ COMMITTED

隔离级别的事务在每次查询开始时都会生成一个独立的

ReadView

3.2.2 REPEATABLE READ

对于使用

REPEATABLE READ

隔离级别的事务来说,只会在第一次执行查询语句时生成一个

ReadView

,之后的查询就不会重复生成了。比方说现在系统里有两个

事务id

分别为

100

200

的事务在执行:

# Transaction 100BEGIN;UPDATE hero SET name ='赵云'WHERE number =1;UPDATE hero SET name ='法正'WHERE number =1;
# Transaction 200BEGIN;# 更新了一些别的表的记录...

此刻,表

hero

number

1

的记录得到的版本链表如下所示:

在这里插入图片描述
假设现在有一个使用

REPEATABLE READ

隔离级别的事务开始执行:

# 使用REPEATABLE READ隔离级别的事务BEGIN;# SELECT1:Transaction 100、200未提交SELECT*FROM hero WHERE number =1;# 得到的列name的值为'张角'

这个

SELECT1

的执行过程如下:

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

之后,我们把

事务id

100

的事务提交一下:

# Transaction 100BEGIN;UPDATE hero SET name ='关羽'WHERE number =1;UPDATE hero SET name ='张飞'WHERE number =1;COMMIT;

然后再到事务

id

200

的事务中更新一下表

hero

number

1

的记录:

# Transaction 200BEGIN;# 更新了一些别的表的记录...UPDATE hero SET name ='孙尚香'WHERE number =1;UPDATE hero SET name ='妲己'WHERE number =1;

此刻,表

hero

number

1

的记录的版本链就长这样:

在这里插入图片描述

然后再到刚才使用

REPEATABLE READ

隔离级别的事务中继续查找这个

number

1

的记录,如下:

# 使用REPEATABLE READ隔离级别的事务BEGIN;# SELECT1:Transaction 100、200均未提交SELECT*FROM hero WHERE number =1;# 得到的列name的值为'张角'# SELECT2:Transaction 100提交,Transaction 200未提交SELECT*FROM hero WHERE number =1;# 得到的列name的值仍为'张角'

这个

SELECT2

的执行过程如下:

  • 因为当前事务的隔离级别为REPEATABLE READ,而之前在执行SELECT1时已经生成过ReadView了,所以此时直接复用之前的ReadView,之前的ReadViewm_ids列表的内容就是[100, 200]min_trx_id100max_trx_id201creator_trx_id0
  • 然后从版本链中挑选可见的记录,从图中可以看出,最新版本的列name的内容是'妲己',该版本的trx_id值为200,在m_ids列表内,所以不符合可见性要求,根据roll_pointer跳到下一个版本。
  • 下一个版本的列name的内容是'孙尚香',该版本的trx_id值为200,也在m_ids列表内,所以也不符合要求,继续跳到下一个版本。下一个版本的列name的内容是'法正',该版本的trx_id值为100,而m_ids列表中是包含值为100事务id的,所以该版本也不符合要求,同理下一个列name的内容是'赵云'的版本也不符合要求。继续跳到下一个版本。
  • 下一个版本的列name的内容是'张角',该版本的trx_id值为80,小于ReadView中的min_trx_id100,所以这个版本是符合要求的,最后返回给用户的版本就是这条列‘name’'张角'的记录。

也就是说两次

SELECT

查询得到的结果是

重复

的,记录的列

name

值都是

'张角'

,这就是

可重复读

的含义。如果我们之后再把

事务id

200

的记录提交了,然后再到刚才使用

REPEATABLE READ

隔离级别的事务中继续查找这个

number

1

的记录,得到的结果还是

'张角'

,具体执行过程大家可以自己分析一下。

3.3 MVCC小结

从上边的描述中我们可以看出来,所谓的

MVCC

Multi-Version Concurrency Control ,多版本并发控制

)指的就是在使用

READ COMMITTD

REPEATABLE READ

这两种隔离级别的事务在执行普通的

SELECT

操作时访问记录的版本链的过程,这样子可以使不同事务的

读-写

写-读

操作并发执行,从而提升系统性能。

READ COMMITTD

REPEATABLE READ

这两个隔离级别的一个很大不同就是:生成

ReadView

的时机不同,

READ COMMITTD

在每一次进行普通

SELECT

操作前都会生成一个

ReadView

,而

REPEATABLE READ

只在第一次进行普通

SELECT

操作前生成一个

ReadView

,之后的查询操作都重复使用这个

ReadView

就好了。

**

小提示:

**
我们之前说执行DELETE语句或者更新主键的UPDATE语句并不会立即把对应的记录完全从页面中删除,而是执行一个所谓的delete mark操作,相当于只是对记录打上了一个删除标志位,这主要就是为MVCC服务的,大家可以对比上边举的例子自己试想一下怎么使用。
另外,所谓的MVCC只是在我们进行普通的SEELCT查询时才生效,截止到目前我们所见的所有SELECT语句都算是普通的查询,至于啥是个不普通的查询,我们稍后再说哈~

四、关于purge

大家有没有发现两件事儿:

  • 我们说insert undo在事务提交之后就可以被释放掉了,而update undo由于还需要支持MVCC,不能立即删除掉。我们在学习undo日志的时候,一个事务写的一组undo日志中都有一个Undo Log Header部分,这个Undo Log Header中有一个名为TRX_UNDO_HISTORY_NODE的属性,表示名为History链表的节点。当一个事务提交之后,就会把这个事务的执行过程产生的这一组Update undo日志插入到History链表的头部我们还说过,每个回滚段都对应一个名为Rollbcak Segment Header的页面,这个页面中有两个属性:- TRX_RSEG_HISTORY:表示Histroy链表的基节点- TRX_RSEG_HISTORY_SIZE:表示Histroy链表占用的页面数量也就是说每个回滚段都有一个History链表,一个事务在某个回滚段中写入的一组update undo日志在该事物提交之后就会加入这个回滚段的History链表。系统中存在很多回滚段,这也意味着可能存在很多个History链表。不过加入到History链表的update undo日志所占用的存储空间页没有释放掉,他们总不能一直存在吧,那得用多大的存储空间存放这些undo日志。
  • 为了支持MVCC,对于delete mark操作来说,仅仅是在记录上打一个删除标记,并没有真正将它删除掉。大家应该还记得,在一组undo日志中的Undo Log Header部分有个名为TRX_UNDO_DEL_MARKS的属性,用来标记本组的undo日志中是否包含因delete mark操作二产生的日志,这些打了删除标记的记录也不能一直存在吧?

为了节约空间,我们应该在合适的时候把

update undo

日志以及仅仅被

标记为删除的记录

彻底删除,这个删除操作就是

purge

不过于问题的关健在于这个合适的时候到底是什么时候

update undo

日志和被标记删除的记录都是为了支持

MVCC

而存在的,只要系统中最早产生的

ReadView

不在访问它们,它们的使命就此结束了,就可以丢进历史的垃圾堆里了。一个

ReadView

在什么时候才肯定不会访问某个事物执行过程中产生的undo日志呢?其实,只要我们能保证生成

ReadView

时,某个事物已经提交,那么该

ReadView

肯定就不需要访问事物运行过程中产生的

undo

日志了(因为该事物所改动的最新版均对该

ReadView

可见)。

InnoDB

为此做了两件事:

  • 在一个事务提交时,会为这个事务生成一个名为事务no的值,该值用来表示事务提交的顺序。先提交的事务的事务no值小,后提交的事务的事务no值大。别忘看在一组undo日志中对应的Undo Log Header部分有一个名为TRX_UNDO_TRX_NO的属性。当事务提交时,就把该事物对应的事务no值填到这个属性中,因为事务no代表着各个事务提交的顺序,而History链表又是按照事务提交的顺序来排列各种undo日志,所以History链表中各组的undo日志也是按照对应的事务no来排序的。
  • 一个ReadView结构除了包含前面学习的几个属性之外,还会包含一个事务no的属性。在生成一个ReadView时,会把比当前系统中最大的事务no的值还大1的值赋予这个属性。
InnoDB

还把当前系统中所有的

ReadView

按照创建时间连成了一个链表。当执行

purge

操作时(这个purge操作是在专门的后线程中执行的),就把系统中最早生成的

ReadView

给取出来。如果当前系统中不存在

ReadView

,那就现场创建一个(新创建的这个ReadView的事务no值肯定比当前已经提交的事务的事务no值大)。然后从各个回滚段的

History链表

中取出

事务no

值较小的各组

undo

日志。如果第一组

undo

日志的

事务no

小于当前系统最早生成的

ReadView

事务no

,就意味着该组

undo

日志没有用了,就会从

History链表

中移除,并且释放掉它们占用的存储空间。如果该组

undo

日志包含因

delete mark

操作而产生的

undo

日志(

TRX_UNDO_DEL_MARKS的属性值为1

),那么也需要将对应的标记为删除的记录给彻底删除。

这里我们需要注意的一点,当前系统中系统最早生成的

ReadView

决定了

purge

操作中可以清理哪些

update undo

日志以及

打了删除标记

的记录。如果某个事物使用的

REPEATABLE READ

隔离级别,那么该事物一直复用最初产生的

ReadView

。假如这个事务运行了很久,一直没有提交,那么最早产生的

ReadView

会一直不释放。系统中

updtae undo

日志和

打了删除标记的记录

就会越来越多,表空间对应的文件也会越来越大,一条记录的版本链将越来越长,从而影响系统的性能。

五、总结

  • 并发的事务在运行过程中会出现一些可能引发一致性问题的现象,具体如下:- 脏写:一个事务修改了另一个未提交事务修改过的数据- 脏读:一个事务读到了另一个未提交事务修改过的数据- 不可重复读:一个事务修改了另一个未提交事务读取的数据- 幻读:一个事务先根据某些搜索条件查询出一些记录,在该事务未提交时,另一个事务写入了一些符合那些搜索条件的记录
  • SOL标准中的4种隔离级别:- READ UNCOMMITTED:可能发生脏读、不可重复读和幻读现象- READCOMMITTED:可能发生不可重复读和幻读现象,但是不可能发生脏读现象。- REPEATABLE READ:可能发生幻读现象,但是不可能发生脏读和不可重复读的现象- SERIALIZABLE:各种现象都不可以发生。实际上,MySOLREPEATABLE READ隔离级别下是可以在很大程度上禁止出现幻读现象的。
  • 下面的语句用来设置事务的隔离级别:SET [GLOBALI|SESSION|PERSIST] TRANSACTION ISOLATION LEVEL Level;
  • 聚簇索引记录和undo日志中的roll pointer属性可以串连成一个记录的版本链
  • 通过生成ReadView来判断记录的某个版本的可见性,其中READ COMMITTD在每一次进行普通SELECT操作前都会生成一个ReadView,而REPEATABLE READ只在第一次进行普通SELECT操作前生成一个ReadView,之后的查询操作都重复使用这个ReadView
  • 当前系统中,如果最早生成的 ReadView 不再访问undo日志以及打了删除标记的记录则可以通过purge操作将它们清除。

至此今天的学习就到此结束了,愿您成为坚不可摧的自己~~~

You can’t connect the dots looking forward; you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future.You have to trust in something - your gut, destiny, life, karma, whatever. This approach has never let me down, and it has made all the difference in my life

如果我的内容对你有帮助,请

点赞

评论

收藏

,创作不易,大家的支持就是我坚持下去的动力!

本文章参考:小孩子《MySQL是怎样运行的》
在这里插入图片描述


本文转载自: https://blog.csdn.net/liang921119/article/details/131008641
版权归原作者 multis 所有, 如有侵权,请联系我们删除。

“一文带你了解MySQL之事务隔离级别和MVCC”的评论:

还没有评论