在MySQL的引擎Innodb中，默认的transaction isolation即为REPEATABLE-READ。
下面，从非纯技术角度，结合各种参考资料，分析一下REPEATABLE-READ的实现原理。
#1 知识准备。
##1.1 snapshot read
##2.2 current read
##3.3 MVVC（多版本并发控制）
##4.4 next-key。
#2 REPEATABLE-READ 实现效果（解决丢失更新，可重复读）。
##2.1 略。（网络中有详细的效果截图，自己也可以开多个seesion窗口实验，不再赘述。）
(如果看到此处激动的同志，请看链接:https://tech.meituan.com/innodb-lock.html)
#3 基于上述文章的补充（翻译：以上搬砖，以下.....额，只能说当时上学课堂流的口水，现在流的是眼泪，谨以此文，致歉我那上学时滔滔不绝的数据库老教授）。
#3.1 关于snapshot read的补充。
在上述文章中，提到读加共享锁，写加排他锁能够避免不做事务的并发控制而出现的四种问题(参考：数据库隔离级别)，但是为了减少锁的使用，提高读的并发能力，基于MVCC的思想，设计出读快照的方法。但是有些涉及到底层数据库实现。
关键是解决：如何确定某行记录对一个活跃的事务是否可见（是否能被当前事务select出来）。
在MySQL的每一行中，末尾存在三个隐藏的字段（到底是几个，有说两个的，这个说两个的后来被人称为是害人不浅，蒙蔽了真理。。。。网上也是众说纷纭，稍有不慎就会迷失，但是基于那个两个隐藏字段的理论确实不能解释出现的现象，因此这个大牛说的是我本篇文章所认同的观点：看这里，比我写的好多了）。
在上述链接文章中，关于read veiw的解释让人茅塞顿开，一切现象得以解释，因此可以基本认定是正确的。在此不再赘述。
#3.2 关于可重复读的意外。
在美团的那篇文章中，提到MySQL本身在REPEATABLE-READ级别就可以防止幻读，我做了实验，但是会出现意外，如以下截图。
有人解释说是因为update操作是实时读，所以更新了select，但是这种解释太粗了，我认为是更新了read view（未求证），因为MySQL的read commit的原理就是每次读都更新read view。
#3.3 实践指导思考。
###3.3.1 索引。
因为写的时候会加排他锁，所以，在写的时候，能做到细粒度的锁住最小的数据单元是很重要的，因此，添加合适并且适当的索引，避免间隙锁，更要避免锁表，是在设计数据库和实际操作表中必须要考虑的。
###3.3.2 避免长时间事务所可重复读带来的数据不准确的问题。
未完待续......
