08 | 事务到底是隔离的还是不隔离的？-爱代码爱编程
MySQL45讲
基础篇
08 | 事务到底是隔离的还是不隔离的？
示例：
begin/start transaction 命令并不是一个事务的起点，在执行到它们之后的第一个操作 InnoDB 表的语句，事务才真正启动。若想要马上启动一个事务，使用 start transaction with consistent snapshot。
- 第一种启动方式：一致性视图是在执行第一个快照读语句（如：不加锁的select语句）时创建的，事务 ID 在 遇到 DML 语句时才会分配且按照执行时间严格递增，遇到 select 语句时会生成假的事务 ID；
- 第二种启动方式：一致性视图是在执行 start transaction with consistent snapshot 时创建的，且分配事务 ID。
Tip：在上图中，事务 C 没有显式地使用 begin/commit，表示这个 update 语句本身就是一个事务，语句完成的时候会自动提交。
“快照”在 MVCC 里是怎么工作的？
InnoDB 里面每个事务有一个唯一的事务 ID，叫作 transaction id。它是在事务开始的时候向 InnoDB 的事务系统申请的，是按申请顺序严格递增的。
每次事务更新数据的时候，都会生成一个新的数据版本，并且把 transaction id 赋值给这个数据版本的事务 ID（可以理解为版本号），记为 row trx_id。
也就是说，数据表中的一行记录，可能有多个版本，每个版本有自己的 row trx_id。
举例：
Tip：图中虚线框里是同一行数据的 4 个版本，当前最新版本是 V4，虚线箭头是指 undo log，V1、V2、V3 并不是物理上真实存在，而是每次需要的时候根据当前版本和 undo log 计算出来。
按照可重复读的定义，一个事务启动的时候，能够看到所有已经提交的事务结果。但是之后，这个事务执行期间，其他事务的更新对它不可见。
InnoDB 为每个事务构造了一个数组，用来保存这个事务启动瞬间“活跃”的所有事务 ID。“活跃”指的就是，启动了但还没提交。
视图数组里面事务 ID 的最小值记为低水位，当前系统里面已经创建过的事务 ID 的最大值加 1 记为高水位。
视图数组和高水位，组成当前事务的一致性视图（read-view）。 准确地理解，read-view 表示的是数据的可见性，而视图数组中的数据因为是活跃的，所以不具备可见性，高水位之上是尚未开始的事务，故而也不具备可见性，所以应该说，由视图数组和高水位，确定了当前事务的一致性视图（read-view）。
严格来说，read-view 中主要包含4个比较重要的内容：
- m_ids：表示在生成 read-view 时当前系统中活跃的读写事务的事务 ID 列表
- min_trx_id：表示在生成 read-view 时当前系统中活跃的读写事务中最小的事务 ID ，也就是m_ids中的最小值
- max_trx_id：表示生成 read-view 时系统中应该分配给下一个事务 ID 值
- creator_trx_id：表示生成该ReadView的事务的事务 ID
对于当前事务的启动瞬间来说，一个数据版本的 row trx_id，有以下几种可能：
- 如果落在绿色部分，表示这个版本是已提交的事务或者是当前事务自己生成的，这个数据是可见的
- 如果落在红色部分，表示这个版本是由将来启动的事务生成的，是肯定不可见的
- 如果落在黄色部分，那就包括两种情况：
- 若 row trx_id 在数组中，表示这个版本是由还没提交的事务生成的，不可见
- row trx_id 不在数组中，表示这个版本是已经提交了的事务生成的，可见
InnoDB 利用了“所有数据都有多个版本”的这个特性，实现了“秒级创建快照”的能力。
示例描述：
（1）事务 A 开始前，系统里面只有一个活跃事务 ID 是 99；
（2）事务 A、B、C 的版本号分别是 100、101、102，且当前系统里只有这四个事务；
（3）三个事务开始前，(1,1）这一行数据的 row trx_id 是 90。
第一个有效更新是事务 C，把数据从 (1,1) 改成了 (1,2)，90 这个版本已经成为了历史版本。
第二个有效更新是事务 B，把数据从 (1,2) 改成了 (1,3)，102 又成为了历史版本。
虽然，在事务 A 查询的时候，事务 B 还没有提交，但是它生成的 (1,3) 这个版本已经变成当前版本了。
最后，事务 A 要来读数据，其视图数组是[99,100]。事务 A 查询语句的读数据流程如下：
- 找到 (1,3) 的时候，判断出 row trx_id=101，比高水位大，处于红色区域，不可见；
- 接着，找到上一个历史版本，一看 row trx_id=102，比高水位大，处于红色区域，不可见；
- 再往前找，终于找到了（1,1)，它的 row trx_id=90，比低水位小，处于绿色区域，可见。
一个数据版本，对于一个事务视图来说，除了自己的更新总是可见以外，有三种情况（针对查询语句）：
- 版本未提交，不可见；
- 版本已提交，但是是在视图创建后提交的，不可见；
- 版本已提交，而且是在视图创建前提交的，可见。
事务 A 的查询语句的视图数组是在事务 A 启动的时候生成的，这时候：
- (1,3) 还没提交，属于情况 1，不可见；
- (1,2) 虽然提交了，但是是在视图数组创建之后提交的，属于情况 2，不可见；
- (1,1) 是在视图数组创建之前提交的，可见。
查询是快照读（一致性读），更新是当前读。
更新逻辑
疑问：事务 B 的视图数组是先生成的，之后事务 C 才提交，不是应该看不见 (1,2) 吗，怎么能算出 (1,3) 来？
如果事务 B 在更新之前查询一次数据，这个查询返回的 k 的值确实是 1。
但是，当它要去更新数据的时候，就不能再在历史版本上更新了，否则事务 C 的更新就丢失了。因此，事务 B 此时的 set k=k+1 是在（1,2）的基础上进行的操作。
更新数据都是先读后写的，而这个读，只能读当前的值，称为“当前读”（current read）。
因此，在更新的时候，当前读拿到的数据是 (1,2)，更新后生成了新版本的数据 (1,3)，这个新版本的 row trx_id 是 101。
所以，在执行事务 B 查询语句的时候，一看自己的版本号是 101，最新数据的版本号也是 101，是自己的更新，可以直接使用，所以查询得到的 k 的值是 3。
除了 update 语句外，select 语句如果加上 lock in share mode（读锁） 或 for update（写锁），也是当前读。
疑问：假设事务 C 不是马上提交的，而是变成了下面的事务 C’，会如何？
根据“两阶段锁协议”，事务 C’ 没提交，也就是说 (1,2) 这个版本上的写锁还没释放。而事务 B 是当前读，必须要读最新版本，而且必须加锁，因此必须等到事务 C’ 释放这个锁，才能继续它的当前读。
疑问：事务的可重复读的能力是怎么实现的？
可重复读的核心就是一致性读（consistent read）；而事务更新数据的时候，只能用当前读。如果当前的记录的行锁被其他事务占用的话，就需要进入锁等待。
读提交的逻辑和可重复读的逻辑类似，它们最主要的区别是：
- 在可重复读隔离级别下，只需要在事务开始的时候创建一致性视图，之后事务里的其他查询都共用这个一致性视图。
- 在读提交隔离级别下，每一个语句执行前都会重新算出一个新的视图。
注意：在读提交隔离级别下，start transaction with consistent snapshot 这个用法没有意义，等效于普通的 start transaction。