事务隔离

初始化表

mysql> 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);

 

 

 

 

 

对于事务来讲，如果默认autocommit=1的话，只有执行到语句才会开启事务，这里的AB我们都是可以使用start transaction with consistent snapshot 这个命令，提前开启事务。

 

这里的查询结果是什么呢，直接说答案  事务A是1  事务B是3

 

分析：

在MySQL里，有两个“视图”的概念：

一个是view。它是一个用查询语句定义的虚拟表，在调用的时候执行查询语句并生成结果。创建视图的语法是create view ... ，而它的查询方法与表一样。

另一个是InnoDB在实现MVCC时用到的一致性读视图，即consistent read view，用于支持RC（Read Committed，读提交）和RR（Repeatable Read，可重复读）隔离级别的实现。

 

“快照”在MVCC里是怎么工作的？

 

在可重复读隔离级别下，事务在启动的时候就“拍了个快照”。注意，这个快照是基于整库的。这里并不是直接会让数据库备份，

而每行数据也都是有多个版本的。每次事务更新数据的时候，都会生成一个新的数据版本，并且把transaction id赋值给这个数据版本的事务ID，记为row trx_id。同时，旧的数据版本要保留，并且在新的数据版本中，能够有信息可以直接拿到它。

也就是说，数据表中的一行记录，其实可能有多个版本(row)，每个版本有自己的row trx_id。

 

 

　　　　　　　　　　　　　　图2

语句更新会生成undo log（回滚日志）吗？那么，undo log在哪呢？

 

实际上，图2中的三个虚线箭头，就是undo log；而V1、V2、V3并不是物理上真实存在的，而是每次需要的时候根据当前版本和undo log计算出来的。比如，需要V2的时候，就是通过V4依次执行U3、U2算出来。

 

按照可重复读的定义，一个事务启动的时候，能够看到所有已经提交的事务结果。但是之后，这个事务执行期间，其他事务的更新对它不可见。

 

 

 

 这样，对于当前事务的启动瞬间来说，一个数据版本的row trx_id，有以下几种可能：

　　1.如果落在绿色部分，表示这个版本是已提交的事务或者是当前事务自己生成的，这个数据是可见的；

　　2.如果落在红色部分，表示这个版本是由将来启动的事务生成的，是肯定不可见的；

　　3.如果落在黄色部分，那就包括两种情况

　　　　若 row trx_id在数组中，表示这个版本是由还没提交的事务生成的，不可见；

　　　　若 row trx_id不在数组中，表示这个版本是已经提交了的事务生成的，可见。

 

这里直接最开头3个事务分析

 

 

从图中可以看到，第一个有效更新是事务C，把数据从(1,1)改成了(1,2)。这时候，这个数据的最新版本的row trx_id是102，而90这个版本已经成为了历史版本。

 

第二个有效更新是事务B，把数据从(1,2)改成了(1,3)。这时候，这个数据的最新版本（即row trx_id）是101，而102又成为了历史版本。

 

你可能注意到了，在事务A查询的时候，其实事务B还没有提交，但是它生成的(1,3)这个版本已经变成当前版本了。但这个版本对事务A必须是不可见的，否则就变成脏读了。

 

好，现在事务A要来读数据了，它的视图数组是[99,100]。当然了，读数据都是从当前版本读起的。所以，事务A查询语句的读数据流程是这样的：

　　找到(1,3)的时候，判断出row trx_id=101，比高水位大，处于红色区域，不可见；

　　接着，找到上一个历史版本，一看row trx_id=102，比高水位大，处于红色区域，不可见；

　　再往前找，终于找到了（1,1)，它的row trx_id=90，比低水位小，处于绿色区域，可见。

 

这样执行下来，虽然期间这一行数据被修改过，但是事务A不论在什么时候查询，看到这行数据的结果都是一致的，所以我们称之为一致性读。

 

一个数据版本，对于一个事务视图来说，除了自己的更新总是可见以外，有三种情况：

　　版本未提交，不可见；

　　版本已提交，但是是在视图创建后提交的，不可见；

　　版本已提交，而且是在视图创建前提交的，可见。

 

分析得到：

• (1,3)还没提交，属于情况1，不可见；
• (1,2)虽然提交了，但是是在视图数组创建之后提交的，属于情况2，不可见；
• (1,1)是在视图数组创建之前提交的，可见。

 

更新逻辑

你看图5中，事务B的视图数组是先生成的，之后事务C才提交，不是应该看不见(1,2)吗，怎么能算出(1,3)来？

 

 

 

是的，如果事务B在更新之前查询一次数据，这个查询返回的k的值确实是1。

 

但是，当它要去更新数据的时候，就不能再在历史版本上更新了，否则事务C的更新就丢失了。因此，事务B此时的set k=k+1是在（1,2）的基础上进行的操作。

 

更新数据都是先读后写的，而这个读，只能读当前的值，称为“当前读”（current read）。

 

这里我们提到了一个概念，叫作当前读。其实，除了update语句外，select语句如果加锁，也是当前读。

mysql> select k from t where id=1 lock in share mode;
mysql> select k from t where id=1 for update;

 

再往前一步，假设事务C不是马上提交的，而是变成了下面的事务C’，会怎么样呢？

 

 

两阶段锁协议

 

 

 

而读提交的逻辑和可重复读的逻辑类似，它们最主要的区别是：

 

 

在可重复读隔离级别下，只需要在事务开始的时候创建一致性视图，之后事务里的其他查询都共用这个一致性视图；

在读提交隔离级别下，每一个语句执行前都会重新算出一个新的视图。

 

 

(1,3)还没提交，属于情况1，不可见；

(1,2)提交了，属于情况3，可见。

 

所以，这时候事务A查询语句返回的是k=2。

显然地，事务B查询结果k=3。

 

小结

对于可重复读，查询只承认在事务启动前就已经提交完成的数据；

 

对于读提交，查询只承认在语句启动前就已经提交完成的数据；

 

问题分析

下面的表结构和初始化语句作为试验环境，事务隔离级别是可重复读。现在，我要把所有“字段c和id值相等的行”的c值清零，但是却发现了一个“诡异”的、改不掉的情况。请你构造出这种情况，并说明其原理。

 

 

并发条件下很容易出现更新丢失问题。

比如下面这几种情况。

 

 

第一个例子

所以执行顺序应该是：
1， 事务A select * from t;
2, 事务B update t set c = c + 4; // 只要c或者id大于等于5就行; 当然这行也可以和1调换， 不影响
3, 事务B commit;
4, 事务A update t set c = 0 where id = c; // 当前读； 此时已经没有匹配的行
5， 事务A select * from t;

 

这是典型的“丢失更新”问题。一个事务的更新操作被另外一个事务的更新操作覆盖。在RR状态下，普通select的时候是会获得旧版本数据的，但是update的时候就检索到最新的数据。
解决方法：在读取的过程中设置一个排他锁，在 begin 事务里， select 语句中增加 for update 后缀，这样可以保证别的事务在此事务完成commit前无法操作记录。

 

第二个例子

用新的方式来分析session B’的更新为什么对session A不可见就是：在session A视图数组创建的瞬间，session B’是活跃的，属于“版本未提交，不可见”这种情况。