目录
前言
mvcc 是如何工作的?
数据的更新
前言
mvcc 与一个事物的隔离级别有关,未提交读永远读的是当前值,串行化是通过加锁实现,这两种隔离级别都与mvcc 没有任何关系。只要一提到mvcc应该想到的是读提交以及可重复读,大家有没有想过都是mvcc,为啥这两个隔离级别所呈现的结果有些不一样呢?难道会有两套mvcc 吗?当然不是,对于这个问题,稍后我会说明的。
我先举一个简单的例子。下面是一个表的初始化语句。
CREATE TABLE `t` (`id` int(11) NOT NULL,`k` int(11) DEFAULT NULL,PRIMARY KEY (`id`)
) ENGINE=InnoDB;
insert into t(id, k) values(1,1),(2,2);
sessionA | sessionB | sessionA |
---|---|---|
在此我说明下,sessionA 是在同一个事物下,事务的隔离级别是可重复读,sessionB 是另外一个事物。是不是感觉很神奇,sessionB 对数据操作成功了,sessionA 没有收到任何干扰。
是不是感觉sessionA 在begin 的时候像相机一样为数据表拍了一张快照。而这个快照也是我们常说的一致性读视图即 consistent read view。它的作用是事务执行期间用来定义“我能看到什么数据”。
mvcc 是如何工作的?
在上面我们讲到了快照,大家是不是感觉我在扯淡,100G的库,你也去快照,你要拷贝100G的数据,别人不会拍死你,放心好了拍不死我的。
其实在启动一个事物的时候,并不需要拷贝数据,只需要在事物系统申请一个事物id 叫做 transaction id,这个id 是原子递增的,意味着一个数据库不会出现两个相同的事物id
每行数据也都是有多个版本的。每次事务更新数据的时候,都会生成一个新的数据版本,并且把 transaction id 赋值给这个数据版本的事务 ID,记为 row trx_id。同时,旧的数据版本要保留在undo log 里,并且在新的数据版本中,能够有信息可以直接拿到它。
可以这么说,数据表中的一行记录,其实可能有多个版本,每个版本都有自己的row trx_id。
按照可重复读的定义,一个事物启动的时候,能够看到所有已经提交的事物结果。但是之后其他事物的更新,它却看不见。
它是怎么找到自己能够看见的数据呢,会拿到每个版本的 row trx_id,如果是在我启动以后生成的row trx_id,继续往前找,直到找到自己提交的或者是本事物启动之前提交的。
为了方便比较,在实现上,innodb 为每个事物构建一个数组,用来保存这个事物启动瞬间,当前正在“活跃” 的所有事物ID。“活跃” 指的是,启动了还没有提交的。
数组里面事务 ID 的最小值记为低水位,当前系统里面已经创建过的事务 ID 的最大值加 1 记为高水位。
这个视图数组和高水位,就组成了当前事物的一致性视图。
而数据版本的可见性规则,就是基于数据的 row trx_id 和这个一致性视图的对比结果得到的。
就拿一致性视图而言,规则是这样的:
-
如果 row trx_id 小于这个视图数组的最小值,说明已经提交了,那么这个数据就是可见的。
-
如果 row trx_id 大于这个高水位,肯定不可见呀,说明事物还没有创建
-
如果 row trx_id 在 最小值和高水位之间又有两种情况:row trx_id刚好就在视图数组是说明还没有提交也不可见,不在视图数组里说明提交了就可见。
所以你现在知道了,InnoDB 利用了“所有数据都有多个版本”的这个特性,实现了“秒级创建快照”的能力。
所以一个数据版本,对于一个事务视图来说,除了自己更新总是可见以外,有三种情况:
-
版本未提交,不可见;
-
版本已提交,但是是在视图创建后提交的,不可见;
-
版本已提交,而且是在视图创建前提交的,可见。
下面我在在回到最开始提到的那个问题,读提交为啥又有些不一样呢,让我们在回顾一下什么是读提交,在事务中,我们可以读到已经提交的事物,只要在我事物中的任何一个时刻提交的,我都可以读到。上面的规则对于读提交同样适用,只不过读提交是在每个select语句都会去申请一个transaction id作为它的row trx_id,同时也会构建一个新的事物数组。
数据的更新
上面我们讲到了mvcc,其实只是在select 用到,如果是update ,或者下面的语句。
select k from t where id=1 lock in share mode;
select k from t where id=1 for update;
大家都知道更新数据都是先读后写的,而这个读,只能读当前的值,称为“当前读”(current read)。
或者是select 语句加上了 share mode 共享锁 或者 for update 拍他锁,这些都只能用到当前读,与mvcc 没有一点关系了。
所以这些语句执行后,会对行进行加锁,update 加行锁,share mode 加的是读锁, for update 加的是写锁。读到最新的数据
而这些锁都是两阶段锁,从加锁开始到事物结束。这么做对于数据库来说也是无赖之举,为了保证数据的一致性,是数据的同步技术。