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

begin/start transaction命令并不是一个事务的起点，在执行到它们之后的第一个操作InnoDB表的语句，事务才真正启动。使用start transation with consistent snapshot 这个命令可以马上启动一个事务。

在MySQL中有两个视图的概念：

一个是view。它是一个用于查询语句定义的虚拟表，它的语法是：create view ...。
另一个是InnoDB 在实现MVCC时用到的一致性读视图，即 consistent read view，用于支持RC（Read Commit 读提交）和RR（Repeatable 可重复读）隔离级别实现的。

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

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

如果库有100G，那么启动一个事务就需要拷贝100G数据，这样实现是不现实的。

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

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

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

如图下所示，就是一个记录被多个事务连续更新后的状态。

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

事务启动的时候，以启动的时刻为准，如果一个数据版本低于在事务启动之前生成的，那就可见，如果在启动之后才生成的，那就不可见。

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

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

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

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

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

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

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

当前读，读取的是最新版本，并且需要先获取对应记录的锁，如以下这些 SQL 类型：

1
2
3
4
5
select ... lock in share mode

select ... for update

update 、delete 、insert

例如，要 update 一条记录，在事务执行过程中，如果不加锁，那么另一个事务可以 delete 这条数据并且能成功 commit ，就会产生冲突了。所以 update 的时候肯定要是当前读，得到最新的信息并且锁定相应的记录。

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

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