说说 MVCC 的工作原理 ？

分析&回答

多版本并发控制(MVCC)

InnoDB的MVCC，是通过在每行记录后面保存两个隐藏的列来实现。这两个列，一个保存了行的创建时间，一个保存行的删除时间，并不是实际的时间，而是系统版本号。每开始一个新的事务，系统版本号都会自动递增。事务开始时刻的系统版本号会作为事务的版本号，用来和查询到的每行记录的版本号作比较，MVCC只在可重读读和提交读两种隔离级别下工作。

可重复读下的MVCC的操作方法

• SELECT
  根据以下两个条件检查每行记录：
  1. InnoDB只查询版本早于当前事务版本的数据行(也就是，行的系统版本号小于或等于事务的系统版本号)，这样可以确保事务读取的行，要么是在事务开始前已经存在的，要么是事务自身插入或者修改过的）；
  2. 行的删除版本要么未定义，要么大于当前事务版本号。这可以确保事务读取到的行，在事务之前未被删除。
     只有符合上述两个条件的记录，才能返回作为查询结果。
• INSERT
  为新插入的每一行保存当前系统版本号作为行版本号。
• DELETE
  为删除的每一行保存当前系统版本号作为行删除标识。
• UPDATE
  为插入一行新记录，保存当前系统版本号作为行版本号，同时保存当前系统版本号到原来的行作为行删除标识。

快照读

当执行select操作是innodb默认会执行快照读，会记录下这次select后的结果，之后select 的时候就会返回这次快照的数据，即使其他事务提交了不会影响当前select的数据，这就实现了可重复读了。快照的生成当在第一次执行select的时候，也就是说假设当A开启了事务，然后没有执行任何操作，这时候B insert了一条数据然后commit,这时候A执行 select，那么返回的数据中就会有B添加的那条数据。之后无论再有其他事务commit都没有关系，因为快照已经生成了，后面的select都是根据快照来的。

当前读

对于会对数据修改的操作(update、insert、delete)都是采用当前读的模式。在执行这几个操作时会读取最新的版本号记录，写操作后把版本号改为了当前事务的版本号，所以即使是别的事务提交的数据也可以查询到。假设要update一条记录，但是在另一个事务中已经delete掉这条数据并且commit了，如果update就会产生冲突，所以在update的时候需要知道最新的数据。也正是因为这样所以才导致幻读。

• 在快照读情况下，MySQL通过mvcc来避免幻读。
• 在当前读情况下，MySQL通过next-key来避免幻读

如何解决当前读导致的幻读问题

使用可串行化的隔离级别

SERIALIZABLE会在读取的每一行数据上都加锁，所以可能导致大量的超时和锁竞争的问题。实际应用中也很少用到这个隔离级别，只有在非常需要确保数据的一致性而且可以接受没有并发的情况下，才考虑采用该级别

使用next-key锁

next-key锁是索引行上的一段前开后闭的区间，是MySQL加锁的基本单位，next-key锁也是行锁和间隙锁的组合。

• 行锁
  单个行记录的锁，主键和唯一索引都是行记录的锁模式，避免其它事务执行更新操作时，导致当前事务发生幻读；
• 间隙锁
  间隙锁是索引行上的一段开区间，间隙锁基于非唯一索引实现，由于InnoDB中索引是有序的，当前事务基于非唯一索引更新数据时InnoDB会在非唯一索引上加上间隙锁，阻塞其他事务需要插入的数据行，避免其它事务执行插入操作时，导致当前事务发生幻读；

反思&扩展

说说什么是间隙锁