在MySQL引擎Innodb中，缺省的transaction isolation是REPEATABLE-READ。
下面我们从非纯技术的角度，结合各种参考资料，分析REPEATABLE-READ的实现原理。
#1知识准备。
# # 1.1快照读
# # 2.2当前读
##3.3 MVVC (多版本并发控制) ) ) ) ) ) )。
#4.4下一个-密钥。
#2REPEATABLE-READ效果(可以解决丢失的更新并重复读取)。
##2.1略。 (网络上有详细的效果截图。 自己也可以打开多个seesion窗口进行实验。 省略说明。 ) )
#3基于上述文章的补充(以上，以下，……额，只能说当时学校课上流的口水，现在流的是眼泪。 在这篇文章中，对不起上学时滔滔不绝的数据库老教授。
# 3.1快照读我的补充。
在上述的报道中，叙述了通过在读上加共享锁，对写上排他锁，可以避免由于不进行事务的同时控制而发生的4个问题(参考：数据库的独立性水平)，但是可以减少锁的使用，提高读的同时性但是，有一些与底层数据库的实现有关。
重要的是如何确定活动事务是否显示行记录，以及当前事务是否选择行记录。
MySQL的每一行末尾都有三个隐藏的字段(请参见)。 请参阅。 请参阅。 网络上也有各种各样的说法，稍一疏忽就会迷路，但那两种基于隐场的理论无法解释确实出现的现象。 因此，这个xhdsh说的是我在本文中认可的意见。 看这里，比我写的好得多)。
在上述链接文章中，对read veiw的说明很生硬，说明了所有的现象，所以基本上可以认定是正确的。 这里省略说明。
#3.2关于可重复阅读的新颖性。
美团的文章中说，MySQL本身可以在REPEATABLE-READ水平上防止误读。 我做了实验，会发生以下截图这样的事故。
MySQL在REPEATABLE-READ级别进行幻读
也有人说明update操作是在实时阅读后更新select的，但该说明太粗了。 我想是因为MySQL的read commit的原理是每次阅读时都会更新read view。
#3.3实践指导思考。
###3.3.1索引。
写的时候会加排他锁，所以写的时候，制作细粒度锁最小的数据单位很重要。 因此，在设计数据库和实际操作表中，必须考虑添加适当和适当的索引以避免间隙锁定，进而避免表锁定。
###3.3.2避免长时间重新读取事务所导致的数据不准确。
还没有完成，没有下文……。