08 | 事务到底是隔离的还是不隔离的？

问题：

可重复度隔离级别下，当前事务不受其他事务的影响，好像与世无争。

但是有行锁的时候，一个事务要更新一行，如果刚好有另外一个事务拥有这一行的行锁，它又不会这么超然，会被锁住，进入等待状态。问题是，既然进入了等待状态，那么等到这个事务自己获取到行锁要更新数据的时候，它读到的值又是什么呢？

 

事务启动时机：

begin/start transaction  该命令并不是一个事务的起点，在执行到它们之后的第一个操作InnoDB表的语句，事务才真正启动。    一致性视图是在执行第一个快照读语句时创建的。

start transaction with consistent snapshot  该命令是马上启动一个事务。    一致性视图是在执行该命令的时候创建的。

 

MySQL中两个“视图”的概念：

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

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

 

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

可重复读隔离级别下，事务在启动的时候就“拍了个快照”，这个快照是基于整库的。

按照可重复读的定义，一个事务启动的时候，能够看到所有已经提交的事务结果。但是之后，这个事务执行期间，其他事务的更新对它不可见。   因此，一个事务只需要在启动的时候声明说，“以我启动的时刻为准，如果一个数据版本是在我启动之前生成的，就认；如果是我启动以后生成的，就不认，必须要找到它的上一个版本（如果上一个版本也不可见，那就的继续往前找）”。

实现方式是，InnoDB为每个事物构造了一个数据，用来保存这个事务启动瞬间，当前正在“活跃”的所有事务ID，“活跃”指的是启动了但还没提交。

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

 

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

1、版本未提交，不可见；

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

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

对下图中三个事务的分析：

k的初始值是1。

B查到的k值是3，而事务A查到的k的值是1。

事务A的查询语句的是图书组是在事务A启动的时候生成的，这时候：

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

（1,2）虽然提交了，但是是在视图创建之后提交的，属于情况2，不可见；

（1,1）是在视图创建之前提交的，可见。

 

更新逻辑

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

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

 

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

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

 

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

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

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

 

上一篇：07 | 行锁功过：怎么减少行锁对性能的影响？

下一篇：09 | 普通索引和唯一索引，应该怎么选择？