带你聊聊MySQL中的事务隔离
按照上图的流程执行，事务B查到的k的值是3，而事务A查到的k的值是1
1、快照在MVCC里是怎么工作的？
在可重复读隔离级别下，事务启动的时候拍了个快照。这个快照是基于整个库的，那么这个快照是如何实现的？
InnoDB里面每个事务有一个唯一的事务ID，叫做transaction id。它在事务开始的时候向InnoDB的事务系统申请，是按申请顺序严格递增的
每行数据也都是有多个版本的。每次事务更新数据的时候，都会生成一个新的数据版本，并且把transaction id赋值给这个数据版本的事务ID，记作row trx_id。同时，旧的数据版本要保留，并且在新的数据版本中，能够有信息可以直接拿到它。也就是说，数据表中的一行记录，其实可能有多个版本，每个版本有自己的row trx_id
下图是一个记录被多个事务连续更新后的状态：
语句更新生成的undo log（回滚日志）就是上图中的是哪个虚线箭头，而V1、V2、V3并不是物理上真实存在的，而是每次需要的时候根据当前版本和undo log计算出来的。比如，需要V2的时候，就是通过V4依次执行U3、U2算出来的
按照可重复读的定义，一个事务启动的时候，能够看到所以已经提交的事务结果。但是之后，这个事务执行期间，其他事务的更新对它不可见。在实现上，InnoDB为每个事务构造了一个数组，用来保存这个事务启动瞬间，当前在启动了但还没提交的所有事务ID。数组里面事务ID的最小值记为低水位，当前系统里面已经创建过的事务ID的最大值加1记为高水位。这个视图数组和高水位就组成了当前事务的一致性视图。而数据的可见性规则，就是基于数据的row trx_id和这个一致性视图的对比结果得到的
这个视图数组把所有的row trx_id分成了几种不同的情况
对于当前事务的启动瞬间来说，一个数据版本的row trx_id，有以下几种可能：
1）如果落在绿色部分，表示这个版本是已提交的事务或者是当前事务自己生成的，这个数据是可见的
2）如果落在红色部分，表示这个版本是由将来启动的事务生成的，肯定不可见
3）如果落在黄色部分，那就包括两种情况
- 若row trx_id在数组中，表示这个版本是由还没提交的事务生成的，不可见
- 若row trx_id不在数组中，表示这个版本是已经提交了的事务生成的，可见
InnoDB利用了所有数据都有多个版本的这个特性，实现了秒级创建快照的能力
2、为什么事务A的查询语句返回的结果是k=1？
假设：
1.事务A开始时，系统里面只有一个活跃事务ID是99
2.事务A、B、C的版本号分别是100、101、102
3.三个事务开始前，(1,1)这一行数据的row trx_id是90
这样，事务A的是数组就是[99,100]，事务B的视图数组是[99,100,101]，事务C的视图数组是[99,100,101,102]
从上图中可以看到，第一个有效更新是事务C，从数据从(1,1)改成了(1,2)。这时候，这个数据的最新版本的row trx_id是102，而90这个版本已经成为了历史版本
第二个有效更新是事务B，把数据从(1,2)改成了(1,3)。这时候，这个数据的最新版本是101，而102又成为了历史版本
在事务A查询的时候，其实事务B还没提交，但是它生成的(1,3)这个版本已经变成当前版本了。但这个版本对事务A必须是不可见的，否则就变成脏读了
现在事务A要读数据了，它的视图数组是[99,100]。读数据都是从当前版本读起的。所以，事务A查询语句的读数据流程是这样的：
- 找到(1,3)的时候，判断出row trx_id=101，比高水位大，处于红色区域，不可见
- 接着，找到上一个历史版本，一看row trx_id=102，比高水位大，处于红色区域，不可见
- 再往前找，终于找到了(1,1)，它的row trx_id=90，比低水位小，处于绿色区域，可见
虽然期间这一行数据被修改过，但是事务A不论在什么时候查询，看到这行数据的结果都是一致的，我们称之为一致性读
一个数据版本，对于一个事务视图来说，除了自己的更新总是可见以外，有三种情况：
- 版本未提交，不可见
- 版本已提交，但是是在视图创建后提交的，不可见
- 版本已提交，而且是在视图创建前提交的，可见
事务A的查询语句的视图数组是在事务A启动的时候生成的，这时候：
- (1,3)还没提交，属于情况1，不可见
- (1,2)虽然提交了，但是是在视图数组创建之后提交的，属于情况2，不可见
- (1,1)是在视图数组创建之前提交的，可见
3、为什么事务B的查询语句返回的结果是k=3？
事务B要去更新数据的时候，就不能再在历史版本上更新了，否则事务C的更新就丢失了。因此，事务B此时的set k=k+1是在(1,2)的基础上进行的操作
更新数据都是先读后写的，而这个读，只能读当前的值，称为当前读。除了update语句外，select语句如果加锁，也是当前读
假设事务C不是马上提交的，而是变成了下面的事务C’，会怎么样？
上图中，事务C更新后没有马上提交，在它提交前，事务B的更新语句先发起了。虽然事务C还没提交，但是(1,2)这个版本也已经生成了，并且是当前的最新版本
这时候涉及到了两阶段锁协议，事务C没提交，也就是说(1,2)这个版本上的写锁还没释放。而事务B是当前读，必须要读最新版本，而且必须加锁，因此就被锁住了，必须等到事务C释放这个锁，才能继续它的当前读
七、事务的可重复读的能力是怎么实现的？
可重复读的核心就是一致性读；而事务更新数据的时候，只能用当前读。如果当前的记录的行锁被其他事务占用的话，就需要进入锁等待
而读提交的逻辑和可重复读的逻辑类似，它们最主要的区别是：
- 在可重复读隔离级别下，只需要在事务开始的时候创建一致性视图，之后事务里的其他查询都共用这个一致性视图
- 在读提交隔离级别下，每一个语句执行前都会重复算出一个新的视图
以上就是带你聊聊MySQL中的事务隔离的详细内容，更多请关注毛票票其它相关文章！