MySQL Innodb在可重复读隔离情况下的实现机制

在Innodb存储引擎下使用了MVCC机制实现了可重复读。所谓MVCC机制就是额外的在每行数据后面增加两列来记录当前行的创建版本号和删除版本号。我们都知道锁在并发操作下对性能的影响很大，正常想法下可能会想到通过使用锁来实现可重复度，但是使用MVCC增加这两列以后就可以在大多数情况下避免使用到锁，从而提高性能。至于增加这两列后为什么能避免在大多数条件下使用到锁可以看下《高性能MySQL》中对MVCC的解释：

简单的查询操作就像我下面的这种情况一样，事务1的版本号比事务2的版本2低，所以事务2更新了数据，事务1也查不到这个更新的数据。
事务1开启后的第一次查询:
事务2进行更新操作并且提交：
事务1继续进行和前面同样的查询：（查不到事务2提交的数据，解决了不可重复读）

但是这里我们要注意的一点就是事务1是在进行了第一个查询操作时才将当前系统版本号设置为事务版本号，所以我们如果事务1仅start transaction，这个时候事务2进行上面同样的操作提交事务，我们再在事务中调用select语句是能查询到事务2更新的操作的。

注意前面书中说的是避免大多数情况下使用到锁，那么说明还是有一些情况下会使用到锁的。在说锁之前先了解一下快照读和当前读。快照读就是读的数据可能是读的过去的数据并不是最新的数据，而当前读就是读的是当前最新的数据。而MVCC是怎么解决实现当前读的这个问题的呢？
通过使用间隙锁。关于什么是间隙锁的内容可以看下这篇博客。https://blog.csdn.net/bigtree_3721/article/details/73731377 而什么情况会用到这个间隙锁实现当前读呢？我们可以通过在语句中加上lock inshare mode使用间隙锁，还有我们在在事务中使用update，insert，delee操作都会使用到这个间隙锁来实现当前读，注意这个是自动加锁的，不用我们加上lock inshare mode这几句。
我上面可能说的不是很清楚，通过一个实例来讲解update操作引发的锁堵塞问题。
事务1开启事务，先进行一个查询操作：

事务2开启（还未提交），并且对行进行更新操作：

事务1也对这行进行更新操作：

我们发现这里出现了一个问题，就是并不能进行更新操作，错误提示是获取锁超时。
为什么会出现上面的问题呢？
前面我们讲到了update操作会对操作行进行加锁操作，所以事务2使用update操作会新增一个行并且对原来那行进行修改删除版本号并且进行一个加锁操作，而事务1使用update操作也是新增一个行并且对原来那行进行一样的操作，但是现在有个问题，事务2的锁还没交出来，事务1怎么去进行修改版本号操作呢。因为这个问题所以就引发了上面那个获取不到锁的问题。只有事务2commit了，事务1才能获取到或者锁。同理两个事务进行delete同一行的操作也会引发同样的问题。（个人理解应该是这个原因，有错欢迎指正，网上也没有找到说法）这里也可以理解为insert、update和delete会更新版本号，是当前读（当前版本）。所以update，insert，delete操作都是依据当前最新版本号来进行的。
还有快照读是通过MVVC(多版本控制)和undo log（日志）来实现的，当前读是通过加record lock(记录锁)和gap lock(间隙锁)来实现的。
还有一个知识点就是乐观锁和悲观锁，其实很简单，乐观锁就是使用我们上面的这种机制。假设不需要锁，而悲观锁就是每个操作都对行进行加锁。所以可以看出乐观锁的性能比悲观锁好，但是数据是最新的。
水平有限，欢迎指正，自己也是刚弄清楚MVCC，快照读，当前读，乐观锁，悲观锁这些知识点的，所以可能有很多错误，发现错误欢迎指正。