《MySQL学习》事务的隔离

一.快照读与当前读

众所周知,MySQL默认的隔离级别为可重复读（RR），开启一致性视图后，事务提交前后数据都是不变的。

事务 T 启动的时候会创建一个视图 read-view，之后事务 T 执行期间，即使有其他事务修改了数据，事务 T 看到的仍然跟在启动时看到的一样。但是如果一个事务准备更新一行数据，而恰好另外一个事务也在更新这一行数据，造成阻塞等待，如果另外一个事务提交后，当前事务恢复后提交再次查询，值是否会变吗？

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

注意：如果使用 begin,那么事务将在执行第一个SQL语句时开启

如果使用 starttransactionwith CONSISTENT SNAPSHOT; 那么事务将在命令执行时开启；

事务A使用 starttransactionwith CONSISTENT SNAPSHOT 最先开启事务，并且只做了DQL操作，那么在事务提交前，数据都是一致不变的，因此事务A的查询结果是 1；

事务B 在事务A开启后使用 starttransactionwith CONSISTENT SNAPSHOT 开启事务，但执行了DML语句，将采用当前读，而事务C 在事务B执行update语句更改为2，首先事务B拿到当前读K的值为2，再加上1，最终查询结果为 3

二. 虚拟表视图与一致性读视图

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

一个是 view。它是一个用查询语句定义的虚拟表，在调用的时候执行查询语句并生成结果。创建视图的语法是 create view … ，而它的查询方法与表一样。
另一个是 InnoDB 在实现 MVCC 时用到的一致性读视图，即 consistent read view，用于支持 RC（Read Committed，读提交）和 RR（Repeatable Read，可重复读）隔离级别的实现。

三.MVCC

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

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

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

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

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

如果落在绿色部分，表示这个版本是已提交的事务或者是当前事务自己生成的，这个数据是可见的；
如果落在红色部分，表示这个版本是由将来启动的事务生成的，是肯定不可见的；
如果落在黄色部分，那就包括两种情况a. 若 row trx_id 在数组中，表示这个版本是由还没提交的事务生成的，不可见；b. 若 row trx_id 不在数组中，表示这个版本是已经提交了的事务生成的，可见。