MySQL实战45讲_8_从一个问题来加深对 mysql 可重复读的理解

我用下面的表结构和初始化语句作为试验环境，事务隔离级别是可重复读。现在，我要把所有 “字段 c 和 id 值相等的行” 的 c 值清零，但是却发现了一个 “诡异” 的、…

引入问题

这个问题来源于一个网络课程的课后思考题，题目是这样的：

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

mysql> CREATE TABLE `test2` (
  `id` int(11) NOT NULL,
  `c` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB;
insert into test2(id, c) values(1,1),(2,2),(3,3),(4,4);

补充解释下这个问题，mysql 环境，innodb 引擎，事务的隔离级别是可重复读，一个表只有两个字段，然后插入 4 条数据，希望你构造上图中的一种情况，就是明明 update 了，但是结果没有更新，select 也好像没有生效。

给出问题的答案

先直接给出答案吧，

开启两个 mysql 的交互窗口，模拟两个事物的操作，比如一个事物叫 A，一个事物叫 B。

流程是这样的，

//事物A
start transaction with consistent snapshot;

//事物B
update test2 set c = c + 4;

//事物A 
update test2 set c = 0 where id = c;

//事物A
select * from test2;

具体操作的截图如下，

A 事物 commit 后 (事物结束)，才可以通过 select 看到真实数据。

解释说明

要理解这个问题的答案，首先需要搞懂什么是可重复读的隔离级别。

可重复读隔离级别，事务 A 启动的时候会创建一个视图 read-view，之后事务 A 执行期间，即使有其他事务修改了数据，事务 A 看到的仍然跟在启动时看到的一样。

我们首先在事物 A 执行 start transaction with consistent snapshot，这个就开始了事物 A 的生命周期，并且是手动事物。因为 start transaction 默认就禁用了 autocommit。

然后事物 B 开始直接执行了 update。为了操作简单这里用了自动事物。也就是事物 B 在 update 后事物就提交了。

这个时候数据变成了下面这个样子：

id	c
1	5
2	6
3	7
4	8

然后事物 A 继续执行 update test2 set c = 0 where id = c;，很明显由于事物 B 已经提交了，事物 A 的 update 的使用的是当前读，判断条件不满足，所以事物 A 不会更新任何数据。

接着，事物 A 执行 select 语句，为什么结果还是以前的数据呢？ 是因为事物 A 的 select 使用的一致读，也叫快照读，读取的还是以前的快照数据。

一致性读是读取在某个时间点已经提交了的数据, 在本示例中，这个时间点就是 start transaction with consistent snapshot执行的时间点。

索引，现在互联网公司大部分会把隔离级别设置成 RC(Read Commited)，也就是读已提交模式。当然除了上面那个问题，还有其它原因，这个不是本文的重点就不展开来讲了。