之前看长事务的危害看过一句话：长事务意味着系统里面会存在很老的事务视图。导致在事务提交前会占用大量存储空间。
那为什么会存在很老的事务视图，事务视图又是什么？
先说说undo log:
事务的回滚日志，是可见性算法 的非常重要的部分，分为两类。
insert undo log：事务在插入新记录产生的undo log，当事务提交之后可以直接丢弃
update undo log：事务在进行 update 或者 delete 的时候产生的 undo log，在快照读的时候还是需要的，所以不能直接删除，只有当系统没有比这个log更早的read-view了的时候才能删除。
对于的事务视图就是read-view了：
读视图，是MySQL秒级创建视图的必要条件，比如一个事务在进行 select 操作(快照读)的时候会创建一个 read-view ，这个read-view 包括两部分。
trx_id：事务id。
数组： 用来保存这个事务启动瞬间，当前正在“活跃”的所有事务ID。“活跃”指的就是，启动了但还没提交。
a.png
这样，对于当前事务的启动瞬间来说，一个数据版本的rowtrx_id，有以下几种可能：
- 如果落在绿色部分，表示这个版本是已提交的事务或者是当前事务自己生成的，这个数据是 可见的；
- 如果落在红色部分，表示这个版本是由将来启动的事务生成的，是肯定不可见的；
-
如果落在黄色部分，那就包括两种情况
a. 若 rowtrx_id在数组中，表示这个版本是由还没提交的事务生成的，不可见；
b. 若 rowtrx_id不在数组中，表示这个版本是已经提交了的事务生成的，可见。
实际上所谓的视图不是真实存在的，是根据undo log一步步推算出来的
b.png
从图中可以看到，第一个有效更新是事务C，把数据从(1,1)改成了(1,2)。这时候，这个数据的最 新版本的rowtrx_id是102，而90这个版本已经成为了历史版本。
第二个有效更新是事务B，把数据从(1,2)改成了(1,3)。这时候，这个数据的最新版本（即row trx_id）是101，而102又成为了历史版本。
你可能注意到了，在事务A查询的时候，其实事务B还没有提交，但是它生成的(1,3)这个版本已 经变成当前版本了。但这个版本对事务A必须是不可见的，否则就变成脏读了。
好，现在事务A要来读数据了，它的视图数组是[99,100]。当然了，读数据都是从当前版本读起 的。所以，事务A查询语句的读数据流程是这样的：
找到(1,3)的时候，判断出rowtrx_id=101，比高水位大，处于红色区域，不可见；
接着，找到上一个历史版本，一看rowtrx_id=102，比高水位大，处于红色区域，不可见；
再往前找，终于找到了（1,1)，它的rowtrx_id=90，比低水位小，处于绿色区域，可见。
这样执行下来，虽然期间这一行数据被修改过，但是事务A不论在什么时候查询，看到这行数据 的结果都是一致的，所以我们称之为一致性读。
读提交的逻辑和可重复读都使用了mvcc
它们最主要的区别是：
在可重复读隔离级别下，只需要在事务开始的时候创建一致性视图，之后事务里的其他查询都共用这个一致性视图；
在读提交隔离级别下，每一个语句执行前都会重新算出一个新的视图。
为什么长事务意味着系统里面会存在很多很老的事务视图
image.png
存在很多很老的事务视图也就是会有很多undo日志
v1的视图执行快照读需要通过v4->v3->2拿到v1版本的数据，若中间的undo日志被删除了，则不能正常执行快照读，所以v1事务不结束的话，v2,v3,v4的undo日志都要存在，因此update undo log只有当系统没有比这个log更早的read-view了的时候才能删除
为什么RR模式不能完全解决幻读
由上面知识我们知道，事务是由undo日志逻辑生成的，而rr模式在当前读的时候也仅仅只会更新读的那部分数据，也就是数据本身当前读之前，事务间的操作是不能被感知的
若是另一个事务操作的数据被当前读了，那么就会产生幻读
a执行快照读->事务b insert一条语句->事务a update b insert的数据（成功了）
摘抄：MySQL实战45讲；https://blog.nowcoder.net/n/cbfedf5aed42484aa1b0f340c6196cc5
网友评论