分析一个MySQL并发事务示例
示例
有这样一张表：
现在有3个事务 A B C 并发执行：
事务A、事务B的select的结果是什么呢？
使用 ”start transaction with consistent snapshot;“ 语句的目的是马上启动事务，”begin/start transaction“命令不是一个事务的起点，而是在执行到他们之后的第一个操作 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);然后开3个mysql client终端，分别代表 A B C，执行：
# client A
start transaction with consistent snapshot;
# client B
start transaction with consistent snapshot;
# client C
update t set k=k+1 where id=1;
# client B
update t set k=k+1 where id=1;
select k from t where id=1; # 3
# client A
select k from t where id=1; # 1
commit;
# client B
commit;结果：
- 事务B的select语句结果是 3
- 事务A的结果是 1
如果你猜对了，也知道是为什么，可以休息了 : )，如果没猜对，那么咱们就一起分析一下。
分析
1. 背景知识
MySQL 默认的事务隔离级别是可重复读，事务在启动时给整个库拍了个快照。
如果一个库有100G，那快照多慢啊，实际快照不是做数据复制，而是基于数据版本日志。
InnoDB里每个事务都有一个唯一的事务ID（transaction id），事务启动时申请，按申请顺序严格递增。
每行数据是有多个版本的，每次事务更新数据的时候，都会生成一个新的版本，并且记录上这个版本是哪个事务ID干的。所以，每行记录都可能有多个版本，每个版本有自己的 row trx_id。
虚线中是同一行数据的4个版本，当前最新版本是 V4，k 值为22，是ID为25的事务更新的。V1 V2 V3 并不是物理存在的，需要的时候可以通过当前版本和 undo log 计算出来。
根据”可重复读“的定义，一个事务启动时，能够看到所有已经提交的事务的结果，事务执行期间，其他事务的更新就不可见了。
所以，就相当于一个事务启动时发出声明：”以我启动时间为准，我只认启动之前的数据版本，如果是我启动之后生成的，我就找之前的数据版本，直到我认可的版本“。
InnoDB 会为每个事务构造一个数组，用来保存在这个事务启动的瞬间正在活跃（已启动但还未提交）的所有事务ID。
例如 transaction id 为 15 的事务启动时，还有事务9、事务12 活跃，那么事务15就有一个数组：[9,12,15]，通过这个数组我们可以明确几件事：
- < 9 的事件肯定都可见，因为都已经执行完成了。
- > 15 的事件肯定都不可见，因为这些事件是后来的。
- 这个数组中，除了自己以为的其他事务的更改结果肯定是不可见的，因为他们在我启动的时候还没提交呢。
- > 9 并且 < 15 的事件中，不在这个数组中的，肯定是可见的，因为他们在我启动时都提交完成了，例如事务10，ID小于我（15），而且在我启动时不是活跃的，说明执行完成了，那么对我来讲他就是可见的。
所以，我们现在知道了，InnoDB 利用 所有数据都有多个版本 这个特性，实现了秒建快照的能力。
2. 示例分析
现在我们回到之前的示例，看看执行过程。
假设：
- 事务A 开始前，只有一个活跃事务 99
- 事务 A B C 的版本号是 100、101、102，当前系统只有这4个事务
- 3个事务开始之前，（1，1）这行数据的 row trx_id = 90
这样，视图数组如下：
- 事务A -> [99, 100]
- 事务B -> [99, 100, 101]
- 事务C -> [99, 100, 101, 102]
2.1事务A的逻辑
第一个有效更新时事务C，这个数据的最新版本的 row trx_id 是 102，90 那个版本成为了历史版本。
第二个有效更新时事务B，这个数据的最新版本的 row trx_id 变成了 101。
然后事务A来读数据了，他的视图数组是 [99,100]，事务A的读取流程是这样的：
- 找到当前版本，一看 row trx_id = 101，比自己视图数组的最大值还大，不可见
- 接着找上一个版本，一看 row trx_id = 102，还是不可见
- 再找上一个版本，row trx_id = 90，比自己视图数组的最小值还小，终于可见了
所以，事务A的查询结果就是 1。
2.2 事务B的逻辑
对于事务B，我们会有一个疑问，根据一致性读规则，结果不对啊，事务B的视图数组是先生成的，事务C后提交的，事务B执行 update 时，不是应该基于 （1，1）吗？怎么会基于（1，2）呢？
这涉及到另一个原则：更新数据时要先读后写，此时读的是”当前版本“，称为 ”当前读（current read）“。
因为更新数据时不能再在历史版本上更新，否则事务C的更新就丢失了，所以事务B的 update 是在（1，2）基础上操作的。
事务B执行 select 时，一看数据的当前版本是 101，是自己更新的，可以直接使用，所以查询结果就是 3 了。
总结
可重复读隔离级别的核心：
- 读数据是一致性读
- 更新数据是当前读
- 如果当前记录的行锁被其他事务占用，进入等锁状态
内容整理自阿里技术专家丁奇的专栏《MySQL实战45讲》