MySQL中的大多数事务性存储引擎实现的都不是简单的行级锁。基于提升并发性能的考虑，他们一般实现了多版本并发控制（mvcc）。不仅是mysql，包括oracle，postgresql等其他数据库也实现了mvcc，但各自的实现机制不尽相同，应为mvcc没有一个统一的实标准。
那么什么是mvvc呢
可以认为mvcc是一个行级锁的变种，但是他们在大多数情况下避免了加锁的操作，因此开销更低。虽然实现的机制不同，但是大都实现了非阻塞的操作，写操作也只锁定必要的行。
mvcc的实现，是通过保存数据在某个时间的快照来实现的。也就是说，不管需要执行多长时间，每个事物看到的数据都是一致的。根据事物开始的时间不同，每个事物对同一张表，同一时刻看到的数据可能不同。
不同的存储引擎对mvcc实现是不同的，典型的有乐观并发控制和悲观并发控制。
InnoDB的mvcc,是通过每行记录后面保存两个隐藏的列来实现的。这两个列，一个保存了创建的时间，一个保存了过期的时间（或删除时间）。当然存储的并不是实际的时间，而是系统的版本号。每开始一个新的事物，系统的版本号就会自动递增。事物开始时刻的系统版本号会作为事物的版本号，用来和查询到的每行记录的版本号进行比较。下面是一个REPEATABLE READ隔离级别下，mvcc具体是如何实现操作的。
select
InnoDB会根据以下两个条件检查每行的记录：
a、InnoDB只查找版本早于当前事物版本的数据行（也就是说，行的版本号小于或等于事物的系统版本号），这样可以确保事物读取的行，要么是在事物开始前已经存在的，要么事物自身插入或 修改的。
b、行的删除版本要么未定义，要么大于当前事物的版本号。这可以确保事物读取到的行，在事物开始前就被删除。
insert
InnoDB为新插入的每一行保存当前版本号作为行的版本号。
delete
InnoDB为删除的每一行保存当前的版本号作为行删除标识。
update
InnoD为插入一行新纪录，保存当前的版本号作为行版本号，同时保存当前系统版本号到原来的行作为删除标识。
保存这两个额外的系统版本号，是大数读操作不用加锁。这样的设计使得读操作很简单，性能很好，并且能够保证只读取到符合标准的行。不足之处就是每行记录都需要额外的空间，需要做更多的行检查工作，以及一些额外的维护工作。
mvcc只在REPEATABLE RED 和 READ COMMITED两个隔离级别下工作。其他的两个隔离级别都和MVCC不兼容，应为READ UNCOMMITTED总是最新的行，而不是符合当前事物版本的数据行。而SERIALIZABLE则会对所有的读取行加锁。