史上最全的超详细理解MVCC(多版本并发控制)

1.介绍

MVCC(Multi Version Concurrency Control),中文名是多版本并发控制, MVCC在MySQL InnoDB中的实现主要是为了提高数据库并发性能,用更好的方式去处理读-写冲突,做到即使有读写冲突时,也能做到不加锁,非阻塞并发读。简单来说就是通过维护数据历史版本,从而解决并发访问情况下的读一致性问题。

2.实现原理

它的实现原理主要是依赖记录中的 3个隐式字段,undo日志 ,Read View 来实现的。
通常数据库中的每行记录除了我们自定义的字段外,还有数据库隐式定义的DB_TRX_ID,DB_ROLL_PTR,DB_ROW_ID三个字段
DB_TRX_ID:最近修改的事务ID,即记录创建这条记录/最后一次修改该记录的事务ID
DB_ROLL_PTR:回滚指针,指向这条记录的上一个版本(存储于rollback segment里)
DB_ROW_ID:隐含的自增ID(隐藏主键),如果数据表没有主键,InnoDB会自动以DB_ROW_ID产生一个聚簇索引

DB_ROW_ID是数据库默认为该行记录生成的唯一隐式主键,DB_TRX_ID是当前操作该记录的事务ID,而DB_ROLL_PTR是一个回滚指针,用于配合undo日志,指向上一个旧版本。

3.Read View

Read View就是事务进行快照读操作的时候生产的读视图(Read View),在该事务执行的快照读的那一刻,会生成数据库系统当前的一个快照,记录并维护系统当前活跃事务的ID(当每个事务开启时,都会被分配一个ID, 这个ID是递增的,所以最新的事务,ID值越大)

Read View主要是用来做可见性判断的, 即当我们某个事务执行快照读的时候,对该记录创建一个Read View读视图,把它比作条件用来判断当前事务能够看到哪个版本的数据,既可能是当前最新的数据,也有可能是该行记录的undo log里面的某个版本的数据。

Read View遵循一个可见性算法,主要是将要被修改的数据的最新记录中的DB_TRX_ID(即当前事务ID)取出来,与系统当前其他活跃事务的ID去对比(由Read View维护),如果DB_TRX_ID跟Read View的属性做了某些比较,不符合可见性,那就通过DB_ROLL_PTR回滚指针去取出Undo Log中的DB_TRX_ID再比较,即遍历链表的DB_TRX_ID(从链首到链尾,即从最近的一次修改查起),直到找到满足特定条件的DB_TRX_ID, 那么这个DB_TRX_ID所在的旧记录就是当前事务能看见的最新老版本.

Read View可以简单的理解成有三个全局属性
trx_list
一个数值列表,用来维护Read View生成时刻系统正活跃的事务ID
up_limit_id
记录trx_list列表中事务ID最小的ID
low_limit_id
ReadView生成时刻系统尚未分配的下一个事务ID,也就是目前已出现过的事务ID的最大值+1;

首先比较DB_TRX_ID (即当前事务ID)< up_limit_id? 如果小于,则当前事务能看到DB_TRX_ID 所在的记录,如果大于等于进入下一个判断
*
判断 DB_TRX_ID >= low_limit_id ? 如果大于等于则代表DB_TRX_ID 所在的记录在Read View生成后才出现的,那对当前事务肯定不可见,如果小于则代表DB_TRX_ID在low和up之间。
*
判断DB_TRX_ID 是否在活跃事务之中,trx_list.contains(DB_TRX_ID),如果在两者之间,则代表生成Read View时,待查询的这个事务还在活跃,还没有Commit,在不可见,如果不在,则说明,这个事务在Read View生成之前就已经Commit了,修改的结果,当前事务可见。

正是Read View生成时机的不同,从而造成RC,RR级别下快照读的结果的不同
在RR级别下的某个事务的对某条记录的第一次快照读会创建一个快照及Read View, 将当前系统活跃的其他事务记录起来,此后在调用快照读的时候,还是使用的是同一个Read View,所以只要当前事务在其他事务提交更新之前使用过快照读,那么之后的快照读使用的都是同一个Read View,所以对之后的修改不可见;

即RR级别下,快照读生成Read View时,Read View会记录此时所有其他活动事务的快照,这些事务的修改对于当前事务都是不可见的。而早于Read View创建的事务所做的修改均是可见
而在RC级别下的,事务中,每次快照读都会新生成一个快照和Read View, 这就是我们在RC级别下的事务中可以看到别的事务提交的更新的原因

总之在RC隔离级别下,是每个快照读都会生成并获取最新的Read View;而在RR隔离级别下,则是同一个事务中的第一个快照读才会创建Read View, 之后的快照读获取的都是同一个Read View。

4。当前读和快照读

当前读

像select lock in share mode(共享锁), select for update ; update, insert ,delete(排他锁)这些操作都是一种当前读,为什么叫当前 读?就是它读取的是记录的最新版本,读取时还要保证其他并发事务不能修改当前记录,会对读取的记录进行加锁。

快照读

像不加锁的select操作就是快照读,即不加锁的非阻塞读;快照读的前提是隔离级别不是串行级别,串行级别下的快照读会退化成当前读;之所以出现快照读的情况,是基于提高并发性能的考虑,快照读的实现是基于多版本并发控制,即MVCC,可以认为MVCC是行锁的一个变种,但它在很多情况下,避免了加锁操作,降低了开销;既然是基于多版本,即快照读可能读到的并不一定是数据的最新版本,而有可能是之前的历史版本

  • 1
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
MVCC(Multi-Version Concurrency Control)是一种并发控制技术,主要用于数据库管理系统中处理并发事务的冲突。MVCC允许事务在取数据时不会被其他事务修改,从而实现了更高的并发性和隔离级别。 在MVCC中,每个事务操作的数据都有多个版本。当一个事务开始时,它会创建一个事务开始时间戳,并且只能看到在该时间戳之前提交的数据版本。而其他事务对同一数据进行修改时,会创建新的数据版本,并将其与修改事务的开始时间戳关联。 基于MVCC的并发控制可以通过以下方式实现: 1. 操作:在取数据时,事务只能看到早于其开始时间戳的已提交版本。这样可以避免脏和不可重复的问题。 2. 写操作:当一个事务进行写操作时,会创建一个新的数据版本,并将其与该事务的开始时间戳关联。其他事务在该事务提交之前只能看到旧版本的数据。 3. 事务隔离级别:MVCC可以支持不同的事务隔离级别,如未提交、已提交、可重复和串行化。这些隔离级别可以根据应用程序的需求进行配置。 MVCC的优点是能够提供更高的并发性和隔离级别,减少了锁的冲突和等待时间。然而,它也会增加存储空间的开销,因为每个数据版本都需要保存。此外,MVCC可能导致长事务持有过多的旧版本数据,增加了垃圾回收的复杂性。 总的来说,MVCC是一种强大的并发控制技术,可以提高并发性和隔离级别,但需要权衡存储空间和垃圾回收的开销。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值