事务获取到行锁时，读到的数据是什么？
事务A要更新一行，假设此时事务B拥有这一行的行锁，那么事务A会被锁住，进入等待状态，事务A等到自己获取到行锁时，读到的值是什么？
示例表：
mysql> 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);
此时有3个事务在执行：
关于事务的执行时机
第一种启动方式：使用begin/start tabsaction命令，并不是真实事务启动的起点，而是在执行到第一个操作innoDB表的语句，事务才真正启动。
第二种启动方式：使用start transaction with consistent snapshot，可以马上启动一个事务。
上图的例子中，
- 事务C没有显式使用begin/commit，表示这个update语句本身就是一个事务，语句完成时自动提交；
- 事务B在执行了更新之后，然后执行查询；
- 事务A在一个只读事务中进行查询。
MySQL中，有两个“视图”概念
1.一个是View，是一个用查询语句定义的虚拟表，在调用的时候执行查询语句，并生成结果。创建视图的语法是 create view，它的查询方法与表一样。
2.一个是InnoDB在实现MVCC时，用到的一致性读视图，即consistent read view，用于支持RC(Read Committed，读已提交)和RR(Repetable Read，可重复读)的隔离级别的实现。
“快照”在MVCC里是怎么工作的？
InnoDB 里面每个事务有一个唯一的事务 ID，叫作 transaction id。它是在事务开始的时候向 InnoDB 的事务系统申请的，是按申请顺序严格递增的。
而每行数据也都是有多个版本的。每次事务更新数据的时候，都会生成一个新的数据版本，并且把 transaction id 赋值给这个数据版本的事务 ID，记为 row trx_id。同时，旧的数据版本要保留，并且在新的数据版本中，能够有信息可以直接拿到它。
也就是说，数据表中的一行记录，其实可能有多个版本 (row)，每个版本有自己的 rowtrx_id。
上图是同一行数据的4个版本，最新版本是V4，K的值是22，是被transaction id为25的事务更新，因此row trx_id也是25。
图中的箭头就是 undo log(回滚日志)，而V1，V2，V3并不是物理上真实存在的，而是每次需要的时候通过当前版本和undo log计算出来的。如需要V2的时候，就是通过V4依次执行U3、U2算出来的。
InnoDB为每个事务构造了一个数组，用来保存这个事务启动瞬间，当前正在活跃的所有事务ID。“活跃”是指启动了但是还未提交。
低水位：数组里事务Id的最小值。
高水位：当前系统里面已经创建过事务ID的最大值+1。
这个视图数组和高水位，组成了当前事务的一致性视图（read-view）。
数据版本的可见性规则，就是基于数据的row trx_id和这个一致性视图的对比结果得到。
对于当前事务启动的瞬间来说，一个数据版本的 row trx_id，有以下几种可能：
- 如果落在绿色部分：这个版本是已提交事务或者是当前事务自行生成，可见。
- 如果落在红色部分：这个版本由将来启动的事务生成，不可见。
- 如果落在黄色部分：包含两种情况：1.若row trx_id在数组中，表示这个版本是由还没提交的事务生成的，不可见。 2.若row trx_id不在数组中，表示这个版本是应提交的事务生成的，可见。
对于下图中的数据来说，如果有一个事务A，它的低水位是18，那么访问这一行数据时，V4通过U3计算出V3，所以在事务A看来这一行的值是11.
InnoDB利用了“所有数据都有多个版本”这个特性，实现了“秒级创建快照”的能力。
回头分析文章开头的三个事务执行流程：
示例数据：
mysql> 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);
为什么事务A的语句返回的结果，是K=1？
做如下假设：
1.事务A开始前，系统里只有一个活跃事务，ID是99。
2.事务A、B、C的版本号分别是100、101、102，且当前系统里只有这4个事务；
3.3个事务开始前，(1,1)这一行数据的row trx_id是90。
这样，事务A的视图数组就是[99,100]，
事务B的视图数组是[99,100,101],
事务C的视图数组是[99,100,101,102]
排除干扰，这里只关注事务A查询过程中的操作：
事务A查询过程中，第一个有效的事务是事务C，事务C将数据(1,1)改成(1,2)，此时，这行数据最新版本的row trx_id是102，而90这个版本已经成为历史版本。
第二个有效更新事务是事务B，把数据从(1,2)改成了(1,3)。此时，这个数据的最新版本(即 row trx_id)是101，而102又成为了历史版本。
但是事务A查询的时候，其实事务B还没提交，但是事务B已经执行了"set k= k+1"，即事务B生成的(1,3)这个版本已经成为当前版本，但是这个版本对事务A不可见，否则就脏读了。
事务A要来读数据了，它的视图数组是[99,100]，读数据都是从当前版本开始读的，所以事务A查询语句的读数据流程如下：
1.找到(1,3)的时候，判断出 row trx_id = 101，比高水位大，处于红色区域，不可见。
2.接着找到上一个历史版本，row trx_id = 102，比高水位大，处于红色区域，不可见。
3.再往前找，找到了(1,1)，它的row trx_id=90，比低水位小，处于绿色区域，可见。
这样执行下来，虽然事务A执行期间这一行数据被事务C，事务B依次修改过，但是事务A不论在什么时候查询，看到这行数据的结果都是一致的，所以称之为 一致性读。
一个数据版本，对于一个事务视图来说，除了自己的更新总是可见意外，有3种情况：
- 版本未提交，不可见。
- 版本已提交，但是在视图创建后提交，不可见。
- 版本已提交，并且是在视图创建前提交的，可见。
更细逻辑
疑问：事务B的update语句，如果按照一致性读，结果不对吧？
事务B的视图数组是先生成的，之后事务C才提交，实际执行是读取到了(1,2)，然后修改为(1,3)。
事务获取到行锁时，读到的数据是什么？
事务A要更新一行，假设此时事务B拥有这一行的行锁，那么事务A会被锁住，进入等待状态，事务A等到自己获取到行锁时，读到的值是什么？
示例表：
mysql> 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);
此时有3个事务在执行：
关于事务的执行时机
第一种启动方式：使用begin/start tabsaction命令，并不是真实事务启动的起点，而是在执行到第一个操作innoDB表的语句，事务才真正启动。
第二种启动方式：使用start transaction with consistent snapshot，可以马上启动一个事务。
上图的例子中，
- 事务C没有显式使用begin/commit，表示这个update语句本身就是一个事务，语句完成时自动提交；
- 事务B在执行了更新之后，然后执行查询；
- 事务A在一个只读事务中进行查询。
MySQL中，有两个“视图”概念
1.一个是View，是一个用查询语句定义的虚拟表，在调用的时候执行查询语句，并生成结果。创建视图的语法是 create view，它的查询方法与表一样。
2.一个是InnoDB在实现MVCC时，用到的一致性读视图，即consistent read view，用于支持RC(Read Committed，读已提交)和RR(Repetable Read，可重复读)的隔离级别的实现。
“快照”在MVCC里是怎么工作的？
InnoDB 里面每个事务有一个唯一的事务 ID，叫作 transaction id。它是在事务开始的时候向 InnoDB 的事务系统申请的，是按申请顺序严格递增的。
而每行数据也都是有多个版本的。每次事务更新数据的时候，都会生成一个新的数据版本，并且把 transaction id 赋值给这个数据版本的事务 ID，记为 row trx_id。同时，旧的数据版本要保留，并且在新的数据版本中，能够有信息可以直接拿到它。
也就是说，数据表中的一行记录，其实可能有多个版本 (row)，每个版本有自己的 rowtrx_id。
上图是同一行数据的4个版本，最新版本是V4，K的值是22，是被transaction id为25的事务更新，因此row trx_id也是25。
图中的箭头就是 undo log(回滚日志)，而V1，V2，V3并不是物理上真实存在的，而是每次需要的时候通过当前版本和undo log计算出来的。如需要V2的时候，就是通过V4依次执行U3、U2算出来的。
InnoDB为每个事务构造了一个数组，用来保存这个事务启动瞬间，当前正在活跃的所有事务ID。“活跃”是指启动了但是还未提交。
低水位：数组里事务Id的最小值。
高水位：当前系统里面已经创建过事务ID的最大值+1。
这个视图数组和高水位，组成了当前事务的一致性视图（read-view）。
数据版本的可见性规则，就是基于数据的row trx_id和这个一致性视图的对比结果得到。
对于当前事务启动的瞬间来说，一个数据版本的 row trx_id，有以下几种可能：
- 如果落在绿色部分：这个版本是已提交事务或者是当前事务自行生成，可见。
- 如果落在红色部分：这个版本由将来启动的事务生成，不可见。
- 如果落在黄色部分：包含两种情况：1.若row trx_id在数组中，表示这个版本是由还没提交的事务生成的，不可见。 2.若row trx_id不在数组中，表示这个版本是应提交的事务生成的，可见。
对于下图中的数据来说，如果有一个事务A，它的低水位是18，那么访问这一行数据时，V4通过U3计算出V3，所以在事务A看来这一行的值是11.
InnoDB利用了“所有数据都有多个版本”这个特性，实现了“秒级创建快照”的能力。
回头分析文章开头的三个事务执行流程：
示例数据：
mysql> 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);
为什么事务A的语句返回的结果，是K=1？
做如下假设：
1.事务A开始前，系统里只有一个活跃事务，ID是99。
2.事务A、B、C的版本号分别是100、101、102，且当前系统里只有这4个事务；
3.3个事务开始前，(1,1)这一行数据的row trx_id是90。
这样，事务A的视图数组就是[99,100]，
事务B的视图数组是[99,100,101],
事务C的视图数组是[99,100,101,102]
排除干扰，这里只关注事务A查询过程中的操作：
事务A查询过程中，第一个有效的事务是事务C，事务C将数据(1,1)改成(1,2)，此时，这行数据最新版本的row trx_id是102，而90这个版本已经成为历史版本。
第二个有效更新事务是事务B，把数据从(1,2)改成了(1,3)。此时，这个数据的最新版本(即 row trx_id)是101，而102又成为了历史版本。
但是事务A查询的时候，其实事务B还没提交，但是事务B已经执行了"set k= k+1"，即事务B生成的(1,3)这个版本已经成为当前版本，但是这个版本对事务A不可见，否则就脏读了。
事务A要来读数据了，它的视图数组是[99,100]，读数据都是从当前版本开始读的，所以事务A查询语句的读数据流程如下：
1.找到(1,3)的时候，判断出 row trx_id = 101，比高水位大，处于红色区域，不可见。
2.接着找到上一个历史版本，row trx_id = 102，比高水位大，处于红色区域，不可见。
3.再往前找，找到了(1,1)，它的row trx_id=90，比低水位小，处于绿色区域，可见。
这样执行下来，虽然事务A执行期间这一行数据被事务C，事务B依次修改过，但是事务A不论在什么时候查询，看到这行数据的结果都是一致的，所以称之为 一致性读。
一个数据版本，对于一个事务视图来说，除了自己的更新总是可见以外，有3种情况：
- 情况1：版本未提交，不可见。
- 情况2：版本已提交，但是在视图创建后提交，不可见。
- 情况3：版本已提交，并且是在视图创建前提交的，可见。
更细逻辑
疑问：事务B的update语句，如果按照一致性读，结果不对吧？
事务B的视图数组是先生成的，之后事务C才提交，实际执行是读取到了(1,2)，然后修改为(1,3)。
如果事务B在更新前有查询的话，那么查询k的返回值确实是1，但是要更新的数据时，不能再历史版本更新，否则事务C的更新会丢失，因此事务B是在(1,2)的基础上执行k = k+1操作的。
所以有这样一条规则：更新数据都是先读后写的，而这个读，只能读当前的值，称为“当前读”（current read）。
在更新的时候，事务B当前读拿到的数据是(1,2)，更新后生成了新版本数据(1,3)，而这个新版本的row trx_id是101，因此在执行事务B查询(get k) 的时候，事务B一看自己的版本是101，而最新数据的版本号也是101,因此读到的值是k=3。
注意：除了update语句外，select语句如果加锁，也会有当前读。
如果把事务 A 的查询语句 select * from t where id=1 修改一下，加上 lock in share mode 或 for update，也都可以读到版本号是 101 的数据，返回的 k 的值是 3。 下面这两个 select 语句，就是分别加了读锁（S 锁，共享锁）和写锁（X 锁，排他锁）。
mysql> select k from t where id=1 lock in share mode;
mysql> select k from t where id=1 for update;
如果事务C不是立马提交，而是变成了下面的事务C'，会怎样？
根据“两阶段锁协议”，此时事务C'没有提交，即(1,2)这个版本上的写锁还没释放，而事务B是当前读，必须读最新版本，且必须加锁，因此就被锁住了，此时事务B必须等到事务C'释放这个锁，才能继续它的当前读。
这里即把 一致性读、当前读、行锁串起来了。
最初的问题：事务的可重复读如何实现？
可重复度的核心是一致性读（consistent read）；而事务更新数据时，只能用当前读。如果当前记录的行锁被其他事务占用，就需要进度锁等待。
读已提交和可重复读的逻辑类似，主要区别如下：
- 在可重复读的隔离级别下，只需要在事务开始的时候创建一致性视图，之后事务里其他查询都用这个一致性视图。
- 在读已提交的隔离级别下，每一个语句执行前都会重新算出一个新的视图。
读已提交隔离级别下，状态图如下：
事务A的查询语句(get k)视图数组是在执行这个语句时创建的，时序上(1,2)、(1,3)的生成时间都在创建这个视图数组之前，但是在这个时刻事务B的(1,3)还没提交，属于情况1（版本未提交，不可见），而此时事务C的(1,2)已经提交了，属于情况3（版本已提交，并且是在视图创建前提交的，可见）。
所以此时事务A查询语句返回的是k=2；
事务B查询返回的是k=3。
小结
InnoDB 的行数据有多个版本，每个数据版本有自己的 row trx_id，每个事务或者语句有自己的一致性视图。普通查询语句是一致性读，一致性读会根据 row trx_id 和一致性视图确定数据版本的可见性。
- 对于可重复读，查询只承认在事务启动前就已经提交完成的数据；
- 对于读提交，查询只承认在语句启动前就已经提交完成的数据；
而当前读，总是读取已经提交完成的最新版本。
