我理解的MVCC内部实现原理
MySQL InnoDB存储引擎，实现的是基于多版本的并发控制协议——MVCC (Multi-Version Concurrency Control) (注：与MVCC相对的，是基于锁的并发控制，Lock-Based Concurrency Control)。MVCC最大的好处，相信也是耳熟能详：读不加锁，读写不冲突。在读多写少的OLTP应用中，读写不冲突是非常重要的，极大的增加了系统的并发性能，这也是为什么现阶段，几乎所有的RDBMS，都支持了MVCC。
对于delete操作，innodb是通过先将要删除的那一行标记为删除，而不是马上清除这一行，因为innodb实现了MVCC，这些undo段用来实现MVCC多版本机制。锁不阻塞读，读也不阻塞写，这样大大提高了并发性。那么在一致性读的时候，怎么才能找到和事务开始的那个版本呢？
主键索引，每个行都有一个事务ID和一个undo ID，这个undo ID指向了这行的先前版本的位置。 非主键索引(辅助索引secondary index），通过先找主键索引再找到undo段。而对于update操作，则是先标记删除，然后insert一个新的行，接下来如果有一致性读，那么查找old version的行的原理和delete操作是一样的
innoDB的行记录格式中有6字节事务ID的和7字节的回滚指针，通过为每一行记录添加这两个额外的隐藏值来实现MVCC，这两个值一个记录这行数据何时被创建，另外一个记录这行数据何时过期（或者被删除）。但是InnoDB并不存储这些事件发生时的实际时间，相反它只存储这些事件发生时的系统版本号。这是一个随着事务的创建而不断增长的数字。每个事务在事务开始时会记录它自己的系统版本号。每个查询必须去检查每行数据的版本号与事务的版本号是否相同。让我们来看看当隔离级别是REPEATABLE READ时这种策略是如何应用到特定的操作的。
* SELECT： 当隔离级别是REPEATABLE READ时select操作，InnoDB必须每行数据来保证它符合两个条件： 1、InnoDB必须找到一个行的版本，它至少要和事务的版本一样老(也即它的版本号不大于事务的版本号)。这保证了不管是事务开始之前，或者事务创建时，或者修改了这行数据的时候，这行数据是存在的。 2、这行数据的删除版本必须是未定义的或者比事务版本要大。这可以保证在事务开始之前这行数据没有被删除。 符合这两个条件的行可能会被当作查询结果而返回。 * INSERT：
InnoDB为这个新行记录当前的系统版本号。 * DELETE：
InnoDB将当前的系统版本号设置为这一行的删除ID。 * UPDATE：
InnoDB会写一个这行数据的新拷贝，这个拷贝的版本为当前的系统版本号。它同时也会将这个版本号写到旧行的删除版本里。 这种额外的记录所带来的结果就是对于大多数查询来说根本就不需要获得一个锁。他们只是简单地以最快的速度来读取数据，确保只选择符合条件的行。这个方案的缺点在于存储引擎必须为每一行存储更多的数据，
做更多的检查工作，处理更多的善后操作。 MVCC只工作在REPEATABLE READ和READ COMMITED隔离级别下。READ UNCOMMITED不是MVCC兼容的，因为查询不能找到适合他们事务版本的行版本；它们每次都只能读到最新的版本。
SERIABLABLE也不与MVCC兼容，因为读操作会锁定他们返回的每一行数据。
并发控制技术：
LBCC：Lock-Based Concurrency Control，基于锁的并发控制。 MVCC：Multi-Version Concurrency Control，基于多版本的并发控制协议。纯粹基于锁的并发机制并发量低，MVCC是在基于锁的并发控制上的改进，主要是在读操作上提高了并发量。 在MVCC并发控制中，读操作可以分成两类： 1）快照读 (snapshot read)：读取的是记录的可见版本 (有可能是历史版本)，不用加锁（共享读锁s锁也不加，所以不会阻塞其他事务的写）。 2）当前读 (current read)：读取的是记录的最新版本，并且，当前读返回的记录，都会加上锁，保证其他事务不会再并发修改这条记录。
