引言
在事务隔离的时候，事务T启动的时候会创建一个视图read-view,之后事务T执行期间，即使有其他事务修改了数据，事务T还是看到和启动时一样的。
在事务分析的过程中我们需要注意事务的起点。
begin/start transaction 命令并不是一个事务的起点，在执行到它们之后的第一个操作 InnoDB 表的语句，事务才真正启动。如果你想要马上启动一个事务，可以使用 start transaction with consistent snapshot 这个命令。
一般默认autocommit=1
那事务隔离具体怎么操作？视图是啥？
一、视图
MYSQL里有两个视图的概念：
1、一个是 view。它是一个用查询语句定义的虚拟表，在调用的时候执行查询语句并生成结果。创建视图的语法是 create view … ，而它的查询方法与表一样。
2、另一个是 InnoDB 在实现 MVCC 时用到的一致性读视图，即 consistent read view，用于支持 RC（Read Committed，读提交）和 RR（Repeatable Read，可重复读）隔离级别的实现。
二、“快照”
在可重复读隔离级别下，事务在启动的时候就“拍了个快照”。注意，这个快照是基于整库的。
实际上并不是说要把整个数据库都拷贝一遍。而是主要记录事务的id。
在InnoDB中里面的每一个事务都有一个唯一id 叫做transaction id。
事务开始的时候像InnoDB申请的。并且有严格的递增顺序。
因为每行数据会有多个版本，每一次事务更新数据的时候都会生成一个新的数据版本，并且吧自己的事务id transaction id 赋值给这个数据版本你的事务ID。
这个属性记录为 row trx_id。同时，旧的数据版本要保留，并且在新的数据版本中，能够有信息可以直接拿到它。
图中的虚线其实是undo log。
怎么实现？
在可重复读中，以事务自己的启动时刻为准，如果一个数据版本是在我启动之前生成的，就可以看见，承认。如果是我启动以后才生成的，我就不认，我必须找到它的上一个版本。
在这个过程中，InnoDB为每一个事务构造了一个数组，用来保存这个事务启动瞬间，当前正在“活跃”的所有事务ID。“活跃指的是”，事务启动但是还没有提交。
数组里面事务 ID 的最小值记为低水位，当前系统里面已经创建过的事务 ID 的最大值加 1 记为高水位。
这个视图数组和高水位，就组成了当前事务的一致性视图（read-view）。
这样，对于当前事务的启动瞬间来说，一个数据版本的 row trx_id，有以下几种可能：
如果落在绿色部分，表示这个版本是已提交的事务或者是当前事务自己生成的，这个数据是可见的；
如果落在红色部分，表示这个版本是由将来启动的事务生成的，是肯定不可见的；
如果落在黄色部分，那就包括两种情况
a. 若 row trx_id 在数组中，表示这个版本是由还没提交的事务生成的，不可见；
b. 若 row trx_id 不在数组中，表示这个版本是已经提交了的事务生成的，可见。
具体例子
现在有事务ABC
1.在事务A开始前，系统里面只有一个活跃事务ID是99；
2.在事务A、B、C的ID为100、101、102；
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事务去查看的时候，就会在历史版本中一个个看，第一个看到101的，不在可见视图中，就是大于100，不看，第二个102，大于100，不看。再来看到90，比低水位小，可看。
这样事务A不论什么时候查询，看到的行数据的结果都是一致的，所以叫做一致性读
再看更新逻辑
更新数据都是先读后写的，而这个读，只能读当前的值，称为“当前读”（current read）。
除了 update 语句外，select 语句如果加锁，也是当前读。
如果把事务 A 的查询语句 select * from t where id=1 修改一下，加上 lock in share mode 或 for update，也都可以读到版本号是 101 的数据，返回的 k 的值是 3。下面这两个 select 语句，就是分别加了读锁（S 锁，共享锁）和写锁（X 锁，排他锁）。