可重复读
如果是可重复读隔离级别，事务 T 启动的时候会创建一个视图 read-view，之后事务 T 执行期间，即使有其他事务修改了数据，事务 T 看到的仍然跟在启动时看到的一样。
如果一个事务要更新一行，刚好有另外一个事务拥有这一行的行锁，会被锁住，进入等待状态
begin/start transaction 命令并不是一个事务的起点，在执行到它们之后的第一个操作 InnoDB 表的语句，事务才真正启动。如果你想要马上启动一个事务，可以使用 start transaction with consistent snapshot 这个命令。
在读提交隔离级别下，就没意义了，等效于普通的 start transaction。
在 MySQL 里，有两个“视图”的概念：
1）一个是 view。它是一个用查询语句定义的虚拟表，在调用的时候执行查询语句并生成结果。创建视图的语法是 create view … ，而它的查询方法与表一样。
2）另一个是 InnoDB 在实现 MVCC 时用到的一致性读视图，即 consistent read view，用于支持 RC（Read Committed，读提交）和 RR（Repeatable Read，可重复读）隔离级别的实现。
InnoDB 里面每个事务有一个唯一的事务 ID，叫做 transaction id。它是在事务开始的时候向 InnoDB 的事务系统申请的，是按申请顺序严格递增的。而每行数据也都是有多个版本的。每次事务更新数据的时候，都会生成一个新的数据版本，并且把 transaction id 赋值给这个数据版本的事务 ID，记为 row trx_id。数据表中的一行记录，其实可能有多个版本 (row)，每个版本有自己的 row trx_id。
各个数据版本并不是物理上真实存在的，而是每次需要的时候根据当前版本和 undo log 计算出来的。比如，需要 V2 的时候，就是通过 V4 依次执行 U3、U2 算出来。
可重复读：
一个事务只需要在启动的时候声明，“以我启动的时刻为准，如果一个数据版本是在我启动之前生成的，就认；如果是我启动以后才生成的，就不认，必须要找到它的上一个版本”。
一个数据版本，对于一个事务视图来说，除了自己的更新总是可见以外，有三种情况：
1）版本未提交，不可见；
2）版本已提交，但是是在视图创建后提交的，不可见；
3）版本已提交，而且是在视图创建前提交的，可见。
当前读规则：
1）更新数据都是先读后写的，而这个读，只能读当前的值，称为“当前读”（current read）。
2）除了 update 语句外，select 语句如果加锁，也是当前读。加上 lock in share mode 或 for update。
可重复读的核心就是一致性读（consistent read）；
而事务更新数据的时候，只能用当前读。
如果当前的记录的行锁被其他事务占用的话，就需要进入锁等待。
读提交的逻辑和可重复读的逻辑类似，它们最主要的区别是：
1）在可重复读隔离级别下，只需要在事务开始的时候创建一致性视图，之后事务里的其他查询都共用这个一致性视图；
2）在读提交隔离级别下，每一个语句执行前都会重新算出一个新的视图。
