目录
简介
MVCC（Multi-Version Concurrency Control）即多版本并发控制，是通过维护数据的历史版本，从而解决并发访问情况下的读一致性问题
相关概念
读锁：
也叫共享锁、S锁。若事务T对数据对象A加上S锁，则事务T可以读A但不能修改A。其他事务只能再对A加S锁，而不能加X锁，直到T释放A上的S 锁。这保证了其他事务可以读A，但在T释放A上的S锁之前不能对A做任何修改。
写锁：
又称排他锁、X锁。若事务T对数据对象A加上X锁，事务T可以读A也可以修改A。其他事务不能再对A加任何锁，直到T释放A上的锁。这保证了其他事务在T释放A上的锁之前不能再读取和修改A。
表锁：
操作对象是数据表。Mysql大多数锁策略都支持表锁，是系统开销最低但并发性最低的一个锁策略。事务T对整个表加读锁，则其他事务可读不可写；若加写锁，则其他事务增删改都不行。
行级锁：
操作对象是数据表中的一行。行级锁是MVCC技术用的比较多的，对系统开销较大，但处理高并发较好。
MVCC使得大部分支持行锁的事务引擎，不再只使用行锁来进行数据库的并发控制，而是把数据库的行锁与行的多个版本结合起来，只需要很小的开销，就可以实现非锁定读，从而大大提高数据库系统的并发性能。
工作流程
InnoDB的MVCC，是通过在每个行纪录后面保存两个隐藏的列来实现的：
这两个列，一个保存了行的创建版本号，一个保存了行的删除版本号。每开始一个新的事务，系统版本号都会自动递增。事务开始时把当前的系统版本号作为事务的版本号，用来和查询到的每行纪录的版本号进行比较。在REPEATABLE READ隔离级别下，MVCC具体的操作如下：
undo log在不考虑redo log 的情况下利用undo log工作的简化过程为：
- 开始事务
- 记录数据行的数据快照到undo log
- 更新数据
- 把undo log写到磁盘
- 把数据写到磁盘
- 提交事务
- 为了保证数据的持久性，数据要在事务提交之前持久化（5在6之前）
- undo log的持久化必须在在数据持久化之前，这样才能保证系统崩溃时，可以用undo log来回滚事务（4在5之前）
Innodb中的隐藏列
Innodb通过undo log保存了已更改行的旧版本的信息的快照。InnoDB的内部实现中为每一行数据增加了三个隐藏列用于实现MVCC。
- DB_TRX_ID：事务 ID。每次发生修改时，都会把事务 ID 复制给DB_TRX_ID，所以它会保存最新的事务 ID。
- DB_ROLL_PTR：回滚指针，指向回滚段的 undo 日志。如果行已经更新，那么重建行更新之前的内容所需要的信息都在里面。
- DB_ROW_ID：行标识，隐藏自增id
一个数据行被多次更新修改，会形成版本链：
- 当前数据行的DB_TRX_ID存着最新的事务ID，DB_ROLL_PTR存着上一个版本的数据行记录
- 上一个版本的数据行记录存着上次修改对应的DB_TRX_ID，也在DB_ROLL_PTR存有上上一个版本的数据行记录
- 以此类推......
SELECT
InnoDB会根据以下两个条件检查每行纪录：
- 只查找行版本号早于当前事务版本号的数据行。这样可以确保事务读取的行，要么是在事务开始前已经存在的，要么是事务自身插入或者修改过的。
- 行的删除版本号，要么未定义，要么大于当前事务版本号。这样可以确保事务读取到的行，在事务开始之前未被删除。
只有符合上述两个条件的纪录，才能作为查询结果返回。
INSERT
InnoDB为插入的每一行保存当前系统版本号作为行版本号。
DELETE
InnoDB为删除的每一行保存当前系统版本号作为行删除标识版本号。
UPDATE（插入新纪录，删除旧记录）
InnoDB为插入的一行新纪录，保存当前系统版本号作为行版本号，同时，保存当前系统版本号到旧记录作为行删除标识。
MVCC优缺点
优点
MVCC在大多数情况下代替了行锁，实现了对读的非阻塞，读不加锁，读写不冲突。
缺点
每行记录都需要额外的存储空间，需要做更多的行维护和检查工作。
注意：
- MVCC手段只适用于Msyql隔离级别中的读已提交（Read committed）和可重复读（Repeatable Read）。Read uncimmitted由于存在脏读，即能读到未提交事务的数据行，所以不适用MVCC（因为MVCC的创建版本和删除版本要在事务提交后才会产生）。
- 串行化是会对所涉及到的表加锁，并非行锁，自然也就不存在行的版本控制问题。
总之，MVCC主要作用于事务性的，有行锁控制的数据库模型。