全网最全的一篇数据库MVCC详解,不全我负责

全网最全的一篇数据库MVCC详解,不全我负责

相关学习推荐:mysql教程

什么是MVCC

全称Multi-Version Concurrency Control,即多版本并发控制,主要是为了提高数据库的并发性能。以下文章都是围绕InnoDB引擎m i j | _ V T W C来讲,因为myIsam不支持事务。

同一行数据平时发生读写请求时,会上锁阻塞住。但mvcc用更好的方式去处理读—写请求,做到在发生读—写请求冲突时不用加锁

这个读是指的快照读,而不是当前读,当前读是一种加锁操作,是悲观锁

那它到底是怎么做到读—写不用加锁的,快照读当前读又是什么鬼,跟着你们的贴心老哥,继续往下看。

全网最全的一篇数据库MVCC详解,不全我负责

当前读、快照读都n & 3 C ? E T是什么鬼

什么是MySQL InnoDB下的当前读和快g 2 W u i i照读?

当前读

它读取的数据库记录,都是当前最新版本,会对当前读取的数据进行加锁,防止其他事务修改数据。是悲观锁的一种操作。

如下操作都是当前读:

  • select lock in share mode (共享锁)

  • select for update (排他锁)

  • update (排他锁)

  • insert (排他锁)

  • delete (排他锁)

  • 串行化事务隔离级别

快照读

快照读的实现是基于多版本并发控制,即MVCC,既然是多版本,那么快照读读到的数据不一定是当前最新的数据,有可能是之* 2 s 8 J历史版本的数据。

如下操作是快照读:

  • 不加锁的select操作(注:事务级别不是串行化)

快照读与mvcc的关系

MVCCC是“维持一个数据的多个版本,使读写操作没有冲突”的一个抽象概念

这个概念需要具体功能去实现,这个具体实现就是快照读。(具体实现2 E @ [ ~ M B下面讲)

听完贴心老哥的讲解,是不是瞬间茅厕顿开

全网最全的一篇数据库MVCC详解,不全我负责

数据库并发场景

  • 读-读:不存在任何问题,也不需要并发控制

  • 读-写:有线程安全问题,可能会造成] H j B事务隔离性问题,可能遇到脏读,幻读,不可重复读

  • 写-写:有线程安全问题,可能会存在更新丢失问题,比如第一类更新丢失,第二类更新丢失

MVCC解决并发哪些问题?

mvcc用来解决读—写冲突的W 6 ~无锁并发控制,就是为事务分配单向增长时间戳。为每个O ^ 2 . x % Z W数据修改保存一个版本,版本与事务时间戳& ] ] _ q相关联

读操作只读取该事务开始前数据库快照

解决问题如下U z | B . ( . ~

  • 并发读-写时| z , C K:可以做到读操作不阻塞写操n B J u [作,同时写操作也不会阻塞读操作。

  • 解决脏读幻读不可重复读W F K {等事务隔离问题,但不能解决上面的写-写 更新丢失问题。

因此有了下面提高并发性能的组合拳

  • MVCC + 悲观锁:MVCC解决读写冲突,悲观锁解决写写冲突

  • MVCC + 乐观锁:MVCC解决读写冲突,乐观锁解决写写冲突

MVCC的实现原理

它的实现原理主要是版本链undo日志Read View 来实现的

版本链

我们数据库中的每行数据,除了我们肉眼看见的数据,还有几个隐藏字段,得开天眼才能看到。分别是db_trx_iddb_roll_pointerdb_row_id

  • db_trx_id

    6byte,最近修改(修改/插入)事务ID:记录创建这条记录/最后一次修改该记录的事务ID

  • db_roll_pointer(版本链关键)

    7byte,回滚指针,指向这条记录上一个版本(存储于rollback segment里)

  • db_row_id

    6byte,隐含的自增ID(隐藏主键),如果数据表没有主键3 ; & s e HInnoDB会自动以db_row_id产生一个聚簇索引

  • 实际还有一个删除flag隐藏0 3 ! , m r u字段, 记录被更新删除并不代表真的删除,而是删除flag变了

全网最全的一篇数据库MVCC详解,不全我负责

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

每次对数据L % [库记录进行改p ? ^ N R动,都会记录一条undo日志,每条G u ` I (undo日志也都有一个roll_pointer属性(INSERT操g -作对应的undo日志没有该属性,因为1 G : v | , F 9 x该记录并没有更早的版本),可以将这些G ~ [undo日志都连P b ;起来串成一个链表,所以现在的情况就像下图一样:

全网最全的一篇数据库MVCC详解,不全我负责

对该记录每次更新后,都会将旧值放到一条undo日志中,就算是该记录u v j . = } # d的一个旧版本,随着更新次Y : O B 2 5数的增多,所有的版本都会被roll_pointer属性连接成一个链表,我们把这个链表称之为版本链,版本链的头节点就是当前记录最新的值。另外,每个版本中还包含生成该版本时对e - E i Y j应的事务id,这个信息很重要,在根据ReadView判断版本可见性的时候会用到。

undo日志

Undo log 主要用于记录数据被修改之前的日志,在表信息修改之前先会把数据拷贝到undoe Y h ; p K R ^ x log里。

事务进行回滚时可以通过undo log 里的日志进行数据还原

Undo log 的用途

  • 保证事务进行rollback时的原子性和一致性,当| . | H ? R [事务进行回滚的时候可以用undo log的数据进行恢复

  • 用于MVCC快照读的数据,在MVCC多版本控制中,通过读取undo log历史版本数据可以实现不同事务版本号都拥有自己独立的快照数据版本

undo log主要分为两种:

  • insert undo log

    代表事务在insert新记J K X录时产3 : # ! fn E V S I m s的undo log , 只在事务回滚时需要,并且在事务提交后可以被立即丢弃

  • update undo log(主要)

    事务在进行update或delete时产生的undo lD P O 0 ? 4og ; 不仅在事务回滚时需要,在快照读时也需要;

    所以不m o t 0 r : r s b能随便删除,只有在快速读或事务回滚不涉及该日志时,对应的日志才会被purgeq : u a 6 g (线程统一清除

Read View(读视图)

事务进行快照读操作的时候生产的读视图(Read Vie{ D r ? rw),在A z %该事务执行的快照读的那一刻,会生成数据库系统当前的一个快照

记录并维护系统当前活跃事务的ID(没有commit,当每个事务开启时,都会被分配一个% 5 ; u U 5ID, 这个ID是递增的,所以越新的事务,ID值越大),是系统中当前不应该被本事R * y } @看到的其他事务id列表

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

Read View几个属性

  • trx_ids: 当前系统活跃(未提交)事务版本号集合。

  • lol s . d $ v f rw_limit_id: 创建当前read view 时“当前系统最大事务版本号+1”。& A o

  • up_limit_id: 创建当前read view 时“系统正处于活跃事务最小版本号

  • creator_trx_i7 ] {d: 创建当前read view的事务版本号;

Read View可见性判断条件

  • db_trx_id < up_limit_id || db_trx_id == creator_trx_id(显示)

    如果数据事务ID小于read view中的最小活跃事务ID,则可以肯定该数据是在当前事务启之前就已经存在了的,所以可以显示

    或者数据的事务ID等于creator_tr7 + S * O O Jx_id ,那么说明这? u h &个数据就是当前事务自己生成的,自己生成的数据自己当然能看见,所以这种情况下此数据也K _ 0 3 P q | h- c 9 8可以显示的。

  • db_trx_id >= low_liP d $ j Zmit_id(不显示)

    如果o _ m ! y数据事务ID大于E ) J P uread view 中的当前系统的最大事务ID,则说明该数据是在当前read view 创建N 8 K ; J _ D Y h之后才产生的,所以数据不显示。如果小于则进入下一个判断

  • db_trx_id是否在活跃事务(trx_ids)中

    • 不存在:则说明read view产生的时候事务已经u c b N 9commit了,这种情况数据则可以显示

    • 已存在:则代表我Read View生成时刻,你这个事务还在活跃,还没有Comp H Y a l n p i umit,你修改的数据,我当前事务也是看不见的。

全网最全的一篇数据库MVCC详解,不全我负责

MVCC和事务隔离级别

上面所讲的Read View用于支持RC(Read CoV { + L I , i {mmitted,读提交)和RR(Repeatable Read,可重复读)隔离级别实现

RR、RC生成时机

  • RC隔离级别O ? d / [ _ `下,是每个快照读都会生成并获V u # ?取最新Read View

  • 而在RR隔离级别下,则是同一个事务中第一个快照读才会创建Read View, 之后的快照读获取的都是同一个Read View,之后的查询就不会( } ?重复生成p x * 7 s f,所以一个事务的{ 0 # B L N m查询结果每次都是一样的

解决幻读问题

  • 快照读I - - d 7 ^ Y i通过MVCC来进行控制的,Z 1 +不用加锁。按照MVCC中规定的“语法”进行增删改查等操作,以避免~ d P幻读。

  • 当前读:通过next-key锁(行6 m , f锁+gaH / 1 G F qp锁)来解决问题的。

RC、RR级别下的InnoDB快照读区别

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

  • 即RR级别下,快照读生成Read View时,Read View会记录此时所有其他活动事务的快照,这些事务的修改对于当前事务都是不可见的。而早于Read View创建的事务所做的修改均是可见= a D V a e x %

  • 而在RC级w F t别下的,事务中,每次快照读都会新生成一个快照和Read View, 这就是我们在RC级别下的事务中1 t ! 9 N 可以看到别的事务提交的更_ . G z %新的原因

总结

从以上的描述中我们可以看出来,所谓的MVCC指的就是在使用READ COMMITTDv C T W Y L bREP& 3 L : & BEATABLE READ这两种隔离级别的事务在执行普通的SEELCT操作时访问记录的版本链的过程,这样子可以使不同事务的读-写写-读操作并发执行,从而提升系统性能

想了解更多编程学习,敬请关注php培训栏目!

以上就是全# # 7网最全的一篇数据库MVCC详解,不全我负责: 4 N K的详细内容。