近期在学习大佬的mysql知识部分;
【mysql】mvcc介绍
关于这个数据库事务,在之前是有进行学习记录的;
重点知识学习(9.3)–[浅入MySQL数据库事务,浅入MVCC]
MVCC: 即多版本并发控制.
注意数据库在存储时,实际上按照行式存储;对于每一行都有三个隐藏的属性;
比如db_row id
:隐藏的主键; (如果数据表没有指定主键,那么该隐藏id就会负责作为主键);
db_trx_id
:当前事务的id;事务的id是在该事务在提交时分配下来的,它是递增的
;
db_roll_ptr
:回滚指针;这个事务指针会指向前一个版本的数据;
比如这样一段案例,对某行数据的姓名进行修改;这通过回滚指针就会将几个数据串联起来;
数据库采用了这样的机制保证事务; 那么此时设想若对某个数据进行了1千万次操作,它是怎么存储的呢?
所以这个回滚指针穿起来的
数据链
,实际上是有存活时间的;
如果这个多条数据不间断的执行,一直在提交,当某次出现没有提交的事务时,那么这个事务数据就不能删除; 该事务可称为活跃事务;
现在来看RR级别[即可重复读级别]
下的MVCC机制;
比如现在要操作一段数据,开始事务后,这个事务id为8的之后数据都无法读取到;
实际上,在MVCC这里还有一个readview
读取视图的概念;
- 首先之前提到的活跃事务数据(前面的未提交数据)会被存入到
m_ids
这样一个集合中;
该集合会存储小于当前事务id的所有未提交的事务
; - 活跃的事务id可以用来判断事务的id是不是比当前的事务id还小;如果比它小,那么就肯定是已提交的事务,因为这个活跃的事务id已经是最小的未提交事务.
为啥说这个MVCC一定会保证可重复读?
由于事务在开始begin时,就会立即创建生成一个readview
读视图;注意这个readview
从该事务开始到提交的这段时间内都是从一而终不变的;
RR级别下的MVCC与幻读的问题
注意MVCC只是初步程度上解决了幻读,并不会完全地解决幻读问题.
先看一个RR级别下MVCC初步解决幻读的案例;
(1) 首先我这里有几个不同id的事务; 在之前的数据中就id 为5 和 7 的事务没有提交
,也就是活跃事务;
在开启当前id为9的事务
时,就得到了一个readview
视图,里面记录了id为5和7的事务没有提交,它执行了一个查询语句,得到结果;
(2)此时id为7的事务
要开始操作了,它在数据表中插入了一条数据.,然后提交了;
(3)但是id为9的事务
还没有提交呢,它不知道id为7
的已经提交了事务,它再次查询,发现数据没变;
看似已经解决了幻读问题啊,为什么又说没解决幻读呢?
刚才上面的普通读取案例被称之为快照读
机制;实际还有一种当前读
机制;
比如说:
update
insert
delete
selete for update
这些语句在执行的时候就会重新建立一个readview
视图;
还是在刚才的案例中,假如第二步之后,即id为7的事务提交了之后;
此时id 为 9 的事务执行了 一个 update 语句;那么触发了当前读,就会重新建立一个readview
;此时发现id为7d的事务已提交,那么此时再查询之前的语句就会发现已经变了;唉,是不是出现幻读了呢