mysql 的read_浅谈MySQL之 REPEATABLE-READ.

在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窗口实验，不再赘述。)

#3 基于上述文章的补充(翻译：以上搬砖，以下.....额，只能说当时上学课堂流的口水，现在流的是眼泪，谨以此文，致歉我那上学时滔滔不绝的数据库老教授)。

#3.1 关于snapshot read的补充。

在上述文章中，提到读加共享锁，写加排他锁能够避免不做事务的并发控制而出现的四种问题(参考：数据库隔离级别)，但是为了减少锁的使用，提高读的并发能力，基于MVCC的思想，设计出读快照的方法。但是有些涉及到底层数据库实现。

关键是解决：如何确定某行记录对一个活跃的事务是否可见(是否能被当前事务select出来)。

在MySQL的每一行中，末尾存在三个隐藏的字段(到底是几个，有说两个的，这个说两个的后来被人称为是害人不浅，蒙蔽了真理。。。。网上也是众说纷纭，稍有不慎就会迷失，但是基于那个两个隐藏字段的理论确实不能解释出现的现象，因此这个大牛说的是我本篇文章所认同的观点：看这里，比我写的好多了)。

在上述链接文章中，关于read veiw的解释让人茅塞顿开，一切现象得以解释，因此可以基本认定是正确的。在此不再赘述。

#3.2 关于可重复读的意外。

在美团的那篇文章中，提到MySQL本身在REPEATABLE-READ级别就可以防止幻读，我做了实验，但是会出现意外，如以下截图。

MySQL在REPEATABLE-READ级别出现幻读

有人解释说是因为update操作是实时读，所以更新了select，但是这种解释太粗了，我认为是更新了read view(未求证)，因为MySQL的read commit的原理就是每次读都更新read view。

#3.3 实践指导思考。

###3.3.1 索引。

因为写的时候会加排他锁，所以，在写的时候，能做到细粒度的锁住最小的数据单元是很重要的，因此，添加合适并且适当的索引，避免间隙锁，更要避免锁表，是在设计数据库和实际操作表中必须要考虑的。

###3.3.2 避免长时间事务所可重复读带来的数据不准确的问题。

未完待续......