SQL进阶理论篇（十一）：什么是MVCC？
文章目录
- 简介
- 什么是MVCC
- 快照读与当前读
- 悲观锁的问题示例
- 参考文献
简介
在MySQL中，默认的隔离级别是可重复读，可以解决脏读和不可重复读的问题，但不能解决幻读问题。如果想要解决幻读问题，就需要采用串行化的方式，通过牺牲数据库的并发事务处理能力，将隔离级别提升到最高。
那有没有一种方式，可以不采用锁机制，而是只通过乐观锁的方式，来解决不可重复度和幻读问题呢？
确实有，MVCC机制就是用来解决这个问题的。在多数情况下，它可以替代行级锁，降低系统的开销（如InnoDB中就是默认开启MVCC机制的，除此之外还有Oracle，DB2是采用多版本读的方式实现隔离级别，但严格来讲不是MVCC）。
大部分的RDBMS都会支持MVCC。
本节将主要介绍以下几部分：
- MVCC机制的思想是什么？
- 为什么RDBMS要采用MVCC机制，只依靠悲观锁还不够么？
什么是MVCC
MVCC的英文全称是Multiversion Concurrency Control，中文翻译过来就是多版本并发控制系统。
顾名思义，MVCC是通过数据行的多个版本管理，来实现数据库的并发控制。
简单的说，它的思想就是保存数据的历史版本。这样我们就可以通过比较版本号来决定数据是否显示出来（具体的规则后面会讲），基于这种乐观锁的机制，我们在读取数据的时候不需要加锁也可以保证事务的隔离性。
先总结一下MVCC的具体作用：
- 解决了读写之间的阻塞问题。通过MVCC可以让读写之间互相不阻塞，即读的时候不会再阻塞写，反之也是一样，从而提高了事务的并发处理能力；
- 降低了死锁的概率。MVCC里采用的是乐观锁的思想，所以读取数据时根本不用加锁，即使是写数据的时候，最多也是只锁定必要的行。降低了锁的数量，自然也降低了死锁的概率。
- 解决一致性读的问题。一致性读又叫做快照读，当我们查询数据库在某个时间点的快照时，只能看到这个时间点之前事务提交更新的结果，而不能看到这个时间点之后事务的提交结果。
快照读与当前读
快照读，读取的是快照数据，不加锁的select语句都属于快照读，如：
SELECT * FROM player WHERE ...
当前读，读取的是最新数据，而不是历史版本的数据。加锁的select，或者对数据进行增删改查的时候，都会进行当前读。
SELECT * FROM player LOCK IN SHARE MODE;
SELECT * FROM player FOR UPDATE;
INSERT INTO player values ...
DELETE FROM player WHERE ...
UPDATE player SET ...
因此，快照读实际上就是普通读，而当前读包括了加锁的读取和DML操作。
悲观锁的问题示例
接下来，我们以一个具体的例子，来讲解一下采用悲观锁思想可能造成的问题。
比如说，我们有个账户金额表 user_balance，包括三个字段，分别是 username 用户名、balance 余额和 bankcard 卡号。其中只有用户A和用户B有账户余额，其他账户的余额都是0。
接着数据库管理员需要查询这张表里的总账户金额，即执行下面语句：
SELECT SUM(balance) FROM user_balance
这个过程里，用户A或者B自行开启了一个事务，做互相转账。
当管理员事务和用户的事务，时间上撞在一起的时候，会出现什么情况呢？
我们举两个例子（例子均来源于参考文献）。
例子一：由于管理员事务的行级锁的存在，导致用户A给用户B转账会存在等待时间。
如图：
为了保证数据的一致性，管理员事务在统计数据的时候，会给用到的数据加上行级锁。
比如说用户A所在数据行被加锁之后，用户A就不能再操作自己的记录了，如果想做update，只能等到管理员事务结束后，锁被释放，才能操作。
这就导致了用户A的体验很不好，多了额外的等待时长。
例子二：死锁。
过程如图：
简单的说，就是管理员在统计的时候，用户B开启了一个事务，给A转账。
管理员事务是一行一行边读边加锁，它先读取用户A的数据，于是持有了用户A数据的行锁，接下来，它应该再读取用户B的数据，再持有用户B数据的行锁。
但是，在它还没有读到用户B的数据之前，用户B就开启了事务，抢先对自己的记录进行了操作，于是用户B持有了自己所在数据行的行锁。
等到管理员事务需要读用户B的数据时，会发现数据行已经被锁上了，咋整，那就只能等呗，于是管理员事务就开始等待用户B数据的锁被释放。
只要用户B的事务正常结束，锁释放，那么管理员事务就能继续加锁，向下执行来完成统计。
但是用户B的事务并没有结束，因为是给用户A转账，因此它还需要update用户A的数据，把多的钱update进去。但问题是用户A的数据已经被管理员事务加锁了，用户B的事务如果想读，该怎么办呢？只能等管理员事务主动释放这个行锁。
于是，场面就变成了，管理员事务在等待用户事务释放B数据的行锁，而用户事务在等待管理员事务释放A数据的行锁，互不相让，死锁了。
这个就是悲观锁的常见问题，不过在基于乐观锁的MVCC里，这种情况发生的概率会很低，具体的我们下节会介绍。
参考文献
- 31丨为什么大部分RDBMS都会支持MVCC？