MySQL 笔记整理（8.b） --事务到底是隔离还是不隔离的？

笔记记录自林晓斌（丁奇）老师的《mysql实战45讲》

（本篇内图片均来自丁奇老师的讲解，如有侵权，请联系我删除）

8.a） --事务到底是隔离还是不隔离的？

　　本周工作较忙，加上懒惰，拖更了，抱歉。

　　接上文，分析下事务a的返回结果，为什么k=1.这里我们做如下假设：

1. 事务a开始前，系统里面只有一个活跃事务，其id是99
2. 事务a，b, c的版本号分别是100,101,102，且当前系统里面只有四个事务。
3. 三个事务开始前，（1,1）这一行数据的row trx_id是90

　　这样，事务a的视图数组就是[99,100],事务b的视图数组是[99,100,101],事务c的视图数组是[99,100,101,102]。为了简化分析，先把其他的干扰语句去掉，只画出事务a查询逻辑有关的操作。

　　

　　　　图4，事务a查询数据逻辑图

　　从图中可以看到，第一个有效更新的是事务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,比高水位大，处于红色区域，不可见。
• 接着查找上一个历史版本，row trx_id = 90,比低水位小，处于绿色区域，可见。

　　这样，虽然期间这一行数据被修改过，事务a不论在什么时候查询，看到的这个行数据的结果都是一致的，即一致性读。以上判断流程是从代码逻辑转译过来的，如你所见，用于人肉分析很麻烦。另一种较好理解的说法是,对于一个数据版本，一个事务视图来说，除了自己的更新总是可见外，有三种情况。

1. 版本未提交，不可见。
2. 版本已提交，但是是在视图创建后提交的，不可见。
3. 版本已提交，且是在视图创建前提交的，可见。

　　现在我们再来看一下图4中的查询结果，事务a的查询语句的视图数组是在事务a启动的时候生成的，此时：

• （1,3）未提交，不可见。
• （1,2）已提交，但是是在视图数组创建之后提交的，不可见。
• （1,1）是在视图创建前提交的，可见。

更新逻辑：

　　你可能有个疑问，事务b的update语句，如果按照一致性读，结果不对呀？如图5所示，事务b的视图数组是先生成的，之后事务c才提交，不是应该看不见（1,2）吗，怎么能算出（1,3）来？

　　

　　图5，事务b的更新逻辑

　　是的，如果事务b在更新操作之前先查询一下，返回的k的值确实是1.但是，当它要更新数据的时候，就不能再历史版本上更新了，否则事务c的更新就丢失了。因此，事务b此时的set k=k+1是在（1,2）的基础上进行的操作。这里用到了这样一条规则：更新数据都是先读后写，而这个读，只能读当前的值，称为“当前读”(current read). 因此，在更新的时候，当前读拿到的数据是（1,2），更新后生成了新版本的数据（1,3），这个心版本的row trx_id是101.所以，在执行事务b查询语句的时候，一看自己的版本号是101，最新数据的版本号也是101，是自己更新的，可以直接使用，所以查询得到的k的值是3。这里我们提到了一个概念，叫作当前读。其实，除了update语句外，select语句如果加锁，也是当前读. 所以，如果把事务a的查询语句select * from t where id = 1修改一下，加上lock in share model或for update，也都是可以读到版本号是101的数据，返回k的值是3.下面中两个select语句，就是分别加了读书(s锁，共享锁)和写锁（x锁，排它锁）。

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

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

　　

　　　　图6，事务a,b,c'的执行流程。

　　事务c'不同的是，更新后没有马上进行提交，在它提交之前，事务b的更新语句先发起了。前面说过了，虽然事务c'还没提交，但是（1,2）这个版本也已经生成了，并且是当前的最新版本，那么事务b的更新语句会如何处理呢？这个时候就用到我们之前提过的“两阶段锁协议”了。事务c'没提交，也就是（1,2）这个版本上的写锁还没释放。而事务b是当前读，必须要读最新版本，而且必须加锁，因此就被锁住了，必须等到事务c'释放这个锁，才能继续它的当前读。

　　

　　　　图7，事务b更新逻辑图(配合事务c')

　　至此，我们把一致性读，当前读和行锁就串起来了。现在我们回到开头的问题，事务的可重复读能力是怎么实现的呢？可重复读的核心就是一致性读（consistent read）;而事务更新数据的时候，只能用当前读。如果当前的记录的行锁被其他事务占用的话，就需要进入锁等待。而读提交的罗辑和可重复读的罗辑类似，它们最主要的区别在于：

• 在可重复读隔离级别下，只需要在事务开始的时候创建一致性视图，之后事务里的其他查询都公用这个一致性视图
• 在读提交隔离级别下，每一个语句执行前都会重新算出一个新的视图。

　

小结：

　　innodb的行数据有多个版本，每个数据版本有自己的row trx_id，每个事务或者语句有自己的一致性视图，普通的查询语句是一致性读，一致性读会根据row trx_id和一致性视图确定数据版本的可见性。

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

　　而当前读，总是读取已经提交完成的最新版本。

　　

上期问题：

　　如果你要删除一个表里面的10000行数据，有以下三种方式：

1. 直接执行 delete from t limit 10000;
2. 在一个连接中循环执行20次delete from t limit 500;
3. 在20个连接中同时执行delete from t limilt 500;

　　你会选择哪种方式，为什么呢？

　　第二种方式相对较好一些。第一种方式里面，单个语句占用时间长，锁的时间也长，而且大事务还会导致主从延迟。第三种方式会人为造成锁冲突。

问题：

　　我用下面的表结构和初始化语句作为实验环境，事务隔离级别是可重复读。现在，我要把”所有字段c和id值相等”的行的c值清0，但是发现了一个“诡异”的，改不掉的情况。请你构造出这种情况，并说明原理。复现出来以后吗，请你再思考一下，在实际的业务开发中有没有可能碰到这个情况？你的应用代码是会不会掉进这个“坑”里，你又是如何解决的呢？

mysql> create table `t` (
  `id` int(11) not null,
  `c` int(11) default null,
  primary key (`id`)
) engine=innodb;
insert into t(id, c) values(1,1),(2,2),(3,3),(4,4);