Bootstrap

MySQL-技术专题-MVCC机制介绍

前提

针对于MySQL的MVCC模式控制多版本并发可见性的问题,主要那肯定是非"快照读"和"当前读"的逻辑莫属了,readView所指的就是快照读的机制。MySQL是如何根据undo log 链条实现read view机制的?谈谈看。

简介

MVCC (Multiversion Concurrency Control),即多版本并发控制技术,它使得大部分支持行锁的事务引擎,不再单纯的使用行锁来进行数据库的并发控制,取而代之的是把数据库的行锁与行的多个版本结合起来,只需要很小的开销,就可以实现非锁定读,从而大大提高数据库系统的并发性能。

MVCC 实现

MVCC是通过保存数据在某个时间点的快照来实现的. 不同存储引擎的MVCC. 不同存储引擎的MVCC实现是不同的,典型的有乐观并发控制和悲观并发控制.

InnoDB的MVCC,是通过在每行记录后面保存两个隐藏的列来实现的,这两个列,分别保存了这个行的创建时间,一个保存的是行的删除时间。这里存储的并不是实际的时间值,而是系统版本号(可以理解为事务的ID),没开始一个新的事务,系统版本号就会自动递增,事务开始时刻的系统版本号会作为事务的ID.

innodb存储的最基本row中包含一些额外的存储信息 DATA_TRX_ID,DATA_ROLL_PTR,DB_ROW_ID,DELETE BIT

  • 6字节的DATA_TRX_ID 标记了最新更新这条行记录的transaction id,每处理一个事务,其值自动+1

  • 7字节的DATA_ROLL_PTR 指向当前记录项的rollback segment的undo log记录,找之前版本的数据就是通过这个指针

  • 6字节的DB_ROW_ID,当由innodb自动产生聚集索引时,聚集索引包括这个DB_ROW_ID的值,否则聚集索引中不包括这个值.,这个用于索引当中

  • DELETE BIT位用于标识该记录是否被删除,这里的不是真正的删除数据,而是标志出来的删除。真正意义的删除是在commit的时候的执行过程

begin->用排他锁锁定该行->记录redo log->记录undo log->修改当前行的值,写事务编号,回滚指针指向undo log中的修改前的行

上述过程确切地说是描述了UPDATE的事务过程,其实undo log分insert和update undo log,因为insert时,原始的数据并不存在,所以回滚时把insert undo log丢弃即可,而update undo log则必须遵守上述过程

下面分别以select、delete、 insert、 update语句来说明:

SELECT

Innodb检查每行数据,确保他们符合两个标准:

  • 1、InnoDB只查找版本早于当前事务版本的数据行(也就是数据行的版本必须小于等于事务的版本),这确保当前事务读取的行都是事务之前已经存在的,或者是由当前事务创建或修改的行

  • 2、行的删除操作的版本一定是未定义的或者大于当前事务的版本号,确定了当前事务开始之前,行没有被删除

符合了以上两点则返回查询结果。

INSERT

InnoDB为每个新增行记录当前系统版本号作为创建ID。

DELETE

InnoDB为每个删除行的记录当前系统版本号作为行的删除ID。

UPDATE

InnoDB复制了一行。这个新行的版本号使用了系统版本号。它也把系统版本号作为了删除行的版本。

这里简单做下总结:

insert操作时 “创建时间”=DB_ROW_ID,这时,“删除时间 ”是未定义的;

update时,复制新增行的“创建时间”=DB_ROW_ID,删除时间未定义,旧数据行“创建时间”不变,删除时间=该事务的DB_ROW_ID;

delete操作,相应数据行的“创建时间”不变,删除时间=该事务的DB_ROW_ID;

select操作对两者都不修改,只读相应的数据

事务的隔离级别与MVCC

MySQL单进程多线程的数据库软件,在事务的并发操作中可能会出现脏读,不可重复读,幻读。

MySQL支持的四种事务隔离级别如下:

  • Read uncommited 就是:事务A可以读到事务B未commit的数据。这种情况也被叫做脏读。

  • Read commited 简单来说就是:事务A可以读到事务B已经commit的数据。

  • Serializable 在该级别下,写会加写锁、读会加读锁,除了读读不互斥,其他组合都互斥,因此可以保证事务串行化顺序执行,可以避免脏读、不可重复读与幻读。

  • Repeatable read 如下图:可重复读要求事务A两次 select 查询出来的结果是一样的,即使中间事务B将id=1的行给修改了,也要保证事务A再读取时,读到的结果也得和第一次读到的结果相同。

可重复读存在幻读读问题,比如事务A开启后按某个范围X读取一次(事务未提交),这时其他事务在该范围X内插入了新的数据,事务A再读时就会将新插入的数据读取出来,当然在MySQL的RR隔离级别下不会再出现这种幻行的问题。

问题的解决得益于:MVCC多版本并发控制的快照读和next-key lock当前读。

RepeatableRead如何实现

以RR隔离级别为例:

你可以像下面这样看一下你的MySQL默认使用的什么隔离级别:

MVCC多版本并发控制也被称为快照读,在RR的隔离级别下,当事务开启时会创建一个视图(Read View),其实这个视图就是所谓的快照。在整个事务存在的期间,一直会使用这个视图。

当你执行begin开启事务之后,MySQL会拍下像下图这样的快照:

trx_ids中记录着MySQL中活跃的且未提交的事务。

假设有事务A、事务B擦不多在同一时刻开启,那这两个事务会分别得到如下的视图。

RR的隔离级别下,事务开启就会得到上图那样的ReadView,并且只要事务不提交这个ReadView就一直有效。

  • 事务A的视图中,它的事务ID=61,此时活跃的事务集合是[61、62],活跃的事务ID中最小的事务id是它本身。下一个事务id应该是63。

  • 事务B的视图中,它的事务ID=62,此时活跃的事务集合是[61、62],活跃的事务ID中最小的事务id是61。下一个事务id应该是63。

先让事务A尝试去读取name列的数据。

它会发现的这行数据的Data_TRX_ID=60,通过和trx_ids对比发现这个事务ID不在活跃的事务id集合trx_ids中,并且小于它本身的60。说明:在事务A开启之前,事务ID=60的事务早就提交过了所以事务A能直接这行数据name = tom。

然后事务B通过update语句尝试去修改这行数据,想将name 改成 jetty。这时MySQL会记录相应的undo log,并以链表的方式串联起来,于是我们会得到下图:

由于事务B将name改成jerry,导致多出一条undo log。这条undo对应的事务ID=事务B的事务ID = 62。并且通过一个指针执向它的上一个undo log记录。

这时如果事务A重新去读,首先它会读取到的记录是name = jerry,但是它也会发现该记录的trx_id = 62 , 比自己的61还大,并且比下一个事务ID63小。说明:它读到记录其实是和自己同时开启的事务修改后的产物,这时他就会沿着undo log链条往前找,直到找到第一个trx_id等于或者小于自己事务ID的记录为止。所以事务A再一次读取到trx_id = 60的记录。这也就是所谓的快照读机制。

另外需要注意的是:就上例来说,在RR的隔离级别下,确实能保证事务A每次读取出来的结果都是一样的,而且在事务B将其修改后,事务A依然能读取出name = tom。但是这时name=tom真的只是个快照,本质上它已经可以算是不存在是数据了

Read Commited如何实现

RR隔离级别下,当事务一开始视图就会被创建出来,并且一直到该事务提交该视图都有效。

Read Commited隔离级别,每次select 都会创建一个新的视图。

使用这个例子:假设事务A和事务B并发开启,并且各自得到了图中的ReadView。然后很快,事务B就将数据name = tom改成了name = jerry(未提交)。那这时事务A去select会检索出什么结果呢?

事务A检索过程:事务A首先会沿着undo log链条从头开始找,于是它首先找到name = jerry的列。但是它也发现该列的trx_id = 62不但比自己的事务ID 60大,而且还在trx_ids这个活跃事务列表中,说明name = jerry是被和自己差不多同时开启的其他事务更改的。它自然也就读不到。

紧接着事务B提交事务,然后事务A重新select会开启一个新的视图,得到如下图:

当事务A沿着undo log链条往下查找时,他发现首先发现的name = jerry的行的trx_id是62,竟然比自己的事务ID61还大,但是进一步发现,这个事务ID62并不在trx_ids中。说明,这个其实是已经被提交了的数据,那直接就意味着其实自己是允许读出这条数据的。这也就是所谓的读已提交机制。

总结

  • 尽可能的使用较低的隔离级别,精心设计索引,并尽量的使用索引访问数据,使加锁变得更加精确,从而减少锁冲突。

  • 尽量减少事务的大小和范围,降低事务产生锁的粒度和级别

  • 尽量一次性的申请好所有的锁,不要进行锁的升级,因为会产生出现死锁的概率。

  • 不同的线程尽可能保证一致性的顺序进行相关的访问各种表的存储信息数据。

  • 尽可能不要进行数据访问相同的数据信息,尽可能的避免间隙锁的产生以及并发插入的营销,导致数据问题不一致。

  • 如果可以可以提升到表锁来切断锁的级别