看一遍就理解:MVCC原理详解 - 知乎 (zhihu.com)
全网最全的一篇数据库MVCC详解,不全我负责-mysql教程-PHP中文网
MVCC全称Multi-Version Concurrency Control,即多版本并发控制。指的就是在使用READ COMMITTD、REPEATABLE READ这两种隔离级别的事务在执行普通的SEELCT操作时访问记录的版本链的过程,这样子可以使不同事务在不加锁的情况下的读-写、写-读操作并发执行,从而提升系统性能。
MVCC实现的关键知识点
1.快照读和当前读
快照读: 读取的是记录数据的可见版本(有旧的版本)。不加锁,普通的select语句都是快照读,如:
select * from core_user where id > 2;
当前读:读取的是记录数据的最新版本,显式加锁的都是当前读
select * from core_user where id > 2 for update; select * from account where id>2 lock in share mode;
- select lock in share mode (共享锁)
- select for update (排他锁)
- update (排他锁)
- insert (排他锁)
- delete (排他锁)
- 串行化事务隔离级别
2.事务版本号
事务每次开启前,都会从数据库获得一个自增长的事务ID,可以从事务ID判断事务的执行先后顺序。这就是事务版本号。
3.隐式字段
对于InnoDB存储引擎,每一行记录都有两个隐藏列trx_id(事务版本号)、roll_pointer(回滚指针),如果表中没有主键和非NULL唯一键时,则还会有第三个隐藏的主键列row_id
4.undo log
undo log,回滚日志,用于记录数据被修改前的信息。在表记录修改之前,会先把数据拷贝到undo log里,如果事务回滚,即可以通过undo log来还原数据。
作用:
- 事务回滚时,保证原子性和一致性。
- 用于MVCC快照读。
5.版本链
多个事务并行操作某一行数据时,不同事务对该行数据的修改会产生多个版本,然后通过回滚指针(roll_pointer),连成一个链表,这个链表就称为版本链。如下:
- 通过版本链,我们就可以看出事务版本号、隐式字段和undo log它们之间的关系
假设现在有一张core_user表,表里面有一条数据,id为1,名字为孙权:
现在开启一个事务A:对core_user表执行
update core_user set name ="曹操" where id=1
,会进行如下流程操作
- 首先获得一个事务ID=100
- 把core_user表修改前的数据,拷贝到undo log
- 修改core_user表中,id=1的数据,名字改为曹操
- 把修改后的数据事务Id=101改成当前事务版本号,并把roll_pointer指向undo log数据地址。
6.Read View
Read View是事务执行SQL语句时,产生的读视图。实际上在innodb中,每个SQL语句执行前都会得到一个Read View。
它主要是用来做可见性判断的,即判断当前事务可见哪个版本的数据
Read view 的几个重要属性
- m_ids:当前系统中那些活跃(未提交)的读写事务ID, 它数据结构为一个List。
- min_limit_id:表示在生成Read View时,当前系统中活跃的读写事务中最小的事务id,即m_ids中的最小值。
- max_limit_id:表示生成Read View时,系统中应该分配给下一个事务的id值,即当前系统最大事务版本号+1。
- creator_trx_id: 创建当前Read View的事务ID
Read view 匹配条件规则如下:
- 如果数据事务ID
trx_id < min_limit_id
,表明生成该版本的事务在生成Read View前,已经提交(因为事务ID是递增的),所以该版本可以被当前事务访问。- 如果
trx_id>= max_limit_id
,表明生成该版本的事务在生成ReadView后才生成,所以该版本不可以被当前事务访问。- 如果
min_limit_id =<trx_id< max_limit_id
,需要分3种情况讨论
- (1).如果
m_ids
包含trx_id
,则代表Read View生成时刻,这个事务还未提交,但是如果数据的trx_id
等于creator_trx_id
的话,表明数据是自己生成的,因此是可见的。- (2)如果
m_ids
包含trx_id
,并且trx_id
不等于creator_trx_id
,则Read View生成时,事务未提交,并且不是自己生产的,所以当前事务也是看不见的;- (3).如果
m_ids
不包含trx_id
,则说明你这个事务在Read View生成之前就已经提交了,修改的结果,当前事务是能看见的。
MVCC实现原理
1.查询一条记录,基于MVCC,是怎样的流程
- 获取事务自己的版本号,即事务ID
- 获取Read View
- 查询得到的数据(最新版本的),然后Read View中的事务版本号进行比较。
- 如果不符合Read View的可见性规则, 即就需要Undo log中历史快照;
- 最后返回符合规则的数据
InnoDB 实现MVCC,是通过
Read View+ Undo Log
实现的,Undo Log 保存了历史快照,Read View可见性规则帮助判断当前版本的数据是否可见。
2.读已提交(RC)隔离级别,存在不可重复读问题的分析历程
创建core_user表,插入一条初始化数据,如下:
隔离级别设置为读已提交(RC),事务A和事务B同时对core_user表进行查询和修改操作。
事务A: select * fom core_user where id=1 事务B: update core_user set name =”曹操”
执行流程如下:
最后事务A查询到的结果是,name=曹操的记录,我们基于MVCC,来分析一下执行流程:
(1). A开启事务,首先得到一个事务ID为100
(2).B开启事务,得到事务ID为101
(3).事务A生成一个Read View
然后回到版本链:开始从版本链中挑选可见的记录:
由图可以看出,最新版本的列name的内容是
孙权
,该版本的trx_id
值为100。开始执行read view可见性规则校验:min_limit_id(100)=<trx_id(100)<102; creator_trx_id = trx_id =100;
由此可得,trx_id=100的这个记录,当前事务是可见的。所以查到是name为
孙权
的记录。(4). 事务B进行修改操作,把名字改为曹操。把原数据拷贝到undo log,然后对数据进行修改,标记事务ID和上一个数据版本在undo log的地址。
![]()
(5) 提交事务
(6) 事务A再次执行查询操作,新生成一个Read View
然后再次回到版本链:从版本链中挑选可见的记录:
从图可得,最新版本的列name的内容是
曹操
,该版本的trx_id
值为101。开始执行Read View可见性规则校验:min_limit_id(100)=<trx_id(101)<max_limit_id(102); 但是,trx_id=101,不属于m_ids集合
因此,
trx_id=101
这个记录,对于当前事务是可见的。所以SQL查询到的是name为曹操
的记录。综上所述,在读已提交(RC)隔离级别下,同一个事务里,两个相同的查询,读取同一条记录(id=1),却返回了不同的数据(第一次查出来是孙权,第二次查出来是曹操那条记录),因此RC隔离级别,存在不可重复读并发问题。
3. 可重复读(RR)隔离级别,解决不可重复读问题的分析
各种事务隔离级别下的Read view工作方式,是不一样的,RR可以解决不可重复读问题,就是跟Read view工作方式有关。
- 在读已提交(RC)隔离级别下,同一个事务里面,每一次查询都会产生一个新的Read View副本,这样就可能造成同一个事务里前后读取数据可能不一致的问题(不可重复读并发问题)。
- 在可重复读(RR)隔离级别下,一个事务里只会获取一次read view,都是副本共用的,从而保证每次查询的数据都是一样的。
还是这个事务A和事务B,如下:
然后执行第2个查询的时候:
事务A再次执行查询操作,复用老的Read View副本,Read View对应的值如下
然后再次回到版本链:从版本链中挑选可见的记录:
![]()
从图可得,最新版本的列name的内容是
曹操
,该版本的trx_id
值为101。开始执行read view可见性规则校验:min_limit_id(100)=<trx_id(101)<max_limit_id(102); 因为m_ids{100,101}包含trx_id(101), 并且creator_trx_id (100) 不等于trx_id(101)
所以,
trx_id=101
这个记录,对于当前事务是不可见的。这时候呢,版本链roll_pointer
跳到下一个版本,trx_id=100
这个记录,再次校验是否可见:min_limit_id(100)=<trx_id(100)< max_limit_id(102); 因为m_ids{100,101}包含trx_id(100), 并且creator_trx_id (100) 等于trx_id(100)
所以,
trx_id=100
这个记录,对于当前事务是可见的,所以两次查询结果,都是name=孙权的那个记录。即在可重复读(RR)隔离级别下,复用老的Read View副本,解决了不可重复读的问题。
4.MVCC是否解决了幻读问题呢?
网络江湖有个传说,说MVCC的RR隔离级别,解决了幻读问题,我们来一起分析一下。
(1)RR级别下,一个快照读的例子,不存在幻读问题
由图可得,步骤2和步骤6查询结果集没有变化,看起来RR级别是已经解决幻读问题啦~
(2)RR级别下,一个当前读的例子
假设现在有个account表
,表中有4条数据,RR级别。
- 开启事务A,执行当前读,查询id>2的所有记录。
- 再开启事务B,插入id=5的一条数据。
流程如下:
显然,事务B执行插入操作时,阻塞了~因为事务A在执行select ... lock in share mode
(当前读)的时候,不仅在id = 3,4 这2条记录上加了锁,而且在id > 2
这个范围上也加了间隙锁。
因此,我们可以发现,RR隔离级别下,加锁的select, update, delete等语句,会使用间隙锁+ 临键锁,锁住索引记录之间的范围,避免范围间插入记录,以避免产生幻影行记录,那就是说RR隔离级别解决了幻读问题?)
(3)这种特殊场景,似乎有幻读问题
其实,上图事务A中,多加了update account set balance=200 where id=5;
这步操作,同一个事务,相同的sql,查出的结果集不同了,这个结果,就符合了幻读的定义~
- 解决幻读问题
快照读:通过MVCC来进行控制的,不用加锁。按照MVCC中规定的“语法”进行增删改查等操作,以避免幻读。
当前读:通过next-key锁(行锁+gap锁)来解决问题的。