数据库事务隔离级别——可重复读详解
概念：在同一个事务内的查询都是事务开始时刻一致的，可重复读是InnoDB引擎的默认事务隔离级别。
单看概念可能理解起来会稍慢，不妨举个例子。
假设在事务A中通过用户Id查找用户两次，本意两次查找的用户信息是要保持一致的，但是事务B在事务A第一次和第二次查找中悄悄更新了用户的信息，导致事务A的前后两次查找不一致，这就是不可重复读。
可重复读具体工作细节是怎么样的呢？
我们可以这样想，既然要实现可重复读，那简单啊，我们只要在事务开启的瞬间备份当前数据库的状态，接下来这个事务都操作备份库，每个事务各自操作各自的备份库就可以实现可重复读了。
如果对于每个要求可重复读的事务都去备份整个库，那得耗费多少性能，一个事务的执行时间得多长，我们在使用InnoDB的可重复读时性能很好的，显然InnoDB的设计者不是用我们这种愚蠢的思路去实现的。
InnoDB是利用一致性读视图（consistent read view）来支持读提交和可重复读的，
在了解一致性读视图之前，我们得先知道一些InnoDB引擎的基础知识。
我们知道InnoDB中每个事务在创建时都会向事务系统申请一个唯一标识自己的ID，
transaction id，InnoDB将每行数据都区分版本，即每次事务更新数据的时候都生成一个版本号，并且将transaction id赋值给这个数据版本的事务ID，记为row trx_id。InnoDB可以通过当前版本回滚到上个版本。
现在我们从版本号角度来解释下可重复读，一个事务以自身版本为参考点，如果一个数据版本先行于我，对不起，我不认，我只认识我在之前的数据版本。
InnoDB为每个事务构造了一个数组，用来保存这个事务启动瞬间，当前正在“活跃”的所有事务ID。“活跃”指的就是，启动了但还没提交。
数组里面事务ID的最小值记为低水位，当前系统里面已经创建过的事务ID的最大值加1记为高水位。视图数组和高水位，就组成了当前事务的一致性视图（read-view）
一个数据版本，对于一个事务视图来说，除了自己的更新总是可见以外，有三种情况：版本未提交，不可见；版本已提交，但是是在视图创建后提交的，不可见；版本已提交，而且是在视图创建前提交的，可见。
