8 事务隔离级别~~更新逻辑

8 事务隔离级别

初始化表

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

Session a	Session b	Session c
start transaction with consistent snapshot;
	start transaction with consistent snapshot;
		update t set k=k+1 where id=1;
	update t set k=k+1 where id=1; select k from t where id=1;
select k from t where id=1; commit;

这里需要注意3个事务的启动时机

begin/start transaction命令并不是一个事务的起点，在执行命令之后的第一个操作innodb表的语句，事务才真正启动，如果想要马上启动一个事务，可以用start transaction with consistent snapshot; 这个命令

--第一种启动方式，一致性视图是在第执行第一个快照读语句时创建的

--第二种方式，一致性视图在执行start transaction with consistent snapshot;时创建的。

这里默认autocommit=1;，事务隔离级别rr

Session b查到的结果是3，sesion a查到的结果是1

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

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

--另一个是innodb在实现MVCC时用到的一致性读视图，即consistent read view,用于支持RC（read commited）和RR（repeatable read）隔离级别的实现。

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

在RR级别下，事务在启动的时候就”拍了个快照”，注意，这个快照是基于整库的。

这个快照是怎么实现的呢？

在innodb里面每个事务都有一个唯一的事务ID，transaction id，在事务开始的时候向innodb的事务系统申请，是按申请顺序严格递增。

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

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

图中虚线框里是同一行数据的4个版本，当前最新版本是V4，k的值是22，它的transaction id为25的事务更新的，所以row trx_id也是25.

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

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

因此，一个事务只需要在启动的时候声明说，”以我启动的时刻为准，如果一个数据版本是在我启动之前生成的，就认；如果是我启动以后才生成的，我就不认，我必须要找到它的上一个版本”。

当然，如果”上一个版本”也不可见，那就得继续往前找，如果是这个事务自己更新的数据，还是要认的。

在实现上，innodb为每个事务构造了一个数组，用来保存这个事务启动瞬间，当前正在”活跃”的所有事务id，活跃是指启动了但还没提交。

数组里面事务id的最小值记为低水位，当前系统里面已经创建过的事务id的最大值加1记为高水位。

这个视图数组和高水位，就组成了当前事务的一致性视图read-view。

而数据版本的可见性规则，就是基于数据的row trx_id和这个一致性视图的对比结果得到的。

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

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

--2 如果落在红色区域，表示这个版本由将来启动的事务生成，是不可见的。

--3 如果落在黄色区域，包括两种情况

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

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

比如，在上上图中的数据来说，如果有一个事务，它的低水位是18，那么当它访问这一行数据时，就会从V4通过U3计算出V3，所以在它看来，这一行的值是11.

Innodb利用了”所有数据都有多个版本”的这个特性，实现了”秒级快照”的能力。

接下来，看下图中的三个事务，分析事务A的语句返回的结果，为什么是k=1

假设：

--1 事务A开始前，系统里面只有一个活跃事务id是99

--2 事务A,B,C的版本号分别为100,101,102，且当前系统里只有这4个事务

--3 三个事务开始前，(1,1)这一行数据的row trx_id是90.

这样，事务A的视图数组就是[99,100],事务B的视图数组时[99,100,101],事务C的视图数组是[99,100,101,102]

从图中看到，第一个有效更新是事务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>99，比高水位大，处于红色区域，不可见。

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

--再往前找，找了(1,1)，它的row trx_id=90<99，比低水位小，处于绿色，可见。

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

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

--1 版本未提交，不可见

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

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

更新逻辑

当要更新数据的时候，就不能在历史版本上去更新了，否则事务C的更新就丢失了，因此，更新数据都是先读后写的，而这个读，只能读当前的值，称为”当前读”current read。

除了update语句外，select语句如果加锁也是当前读。

如果事务A的查询语句select * from t where id=1加锁lock in share mode或者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不是马上提交，变成下面

Session a	Session b	Session c
start transaction with consistent snapshot;
	start transaction with consistent snapshot;
		start transaction with consistent snapshot; update t set k=k+1 where id=1;
	update t set k=k+1 where id=1; select k from t where id=1;
select k from t where id=1; commit;		commit
	commit;

在往前一步，假设事务C不是马上提交，变成下面

这里事务C没有提交，事务b想要当前读就必须等待id=1上的锁，等待c提交或者回滚才能继续它的当前读

这里把一致性读，当前读和行锁就串起来了。

事务的可重复读的能力是怎么实现的？

可重复读的核心就是一致性读，而事务更新数据的时候，只能用当前读，如果当前的记录的行锁被其他事务占有，就需要进入锁等待。

而RC和RR的逻辑类似，最主要的区别就是：

--在RR下，只需要在事务开始的时候创建一个一致性视图，之后的事务的其他查询都公用这个一致性视图

--在RC下，每一个语句执行前都会重新算出一个新的视图。

在RC下查看前面的例子

事务A查询语句的视图在执行语句时候创建的，时序上(1,2),(1,3)的生成时间都是在创建这个视图数组的时刻之前，但是，在这个时刻

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

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

所以，这时候事务A查询到的结果就是k=2.显然地，事务B查询结果K=3.