数据库事务那些事
经过两期的铺垫，这期该给大家聊聊MVCC。今天聊的内容比较干，希望大家做好准备。
多版本并发控制（MVCC）
多版本并发控制（MVCC）——Multi Version Concurrency Control，就是通过多个数据版本来控制并发的操作。很多数据库产品的事务都是运用了这种思想。
实现讨论
多版本并发控制（MVCC）工作在两种隔离级别（读已提交Read Committed和可重复读Repeatable Read）。其他两种隔离级别由于自己身特性的原因与MVCC是不兼容的。
读未提交Read Committed——因为没有明显的事务界限，所以每次读取都是新的数据。
序列化读Serializable Read——因为无论是读还是写都会加X锁，那么读和写的操作会互相阻塞，所以不会出现并发的场景。
MVCC可以看作是对锁机制的一种补偿机制，因为数据库中出现大量并发操作的时候，单单使用锁的机制来控制的话，数据库的处理能力会大打折扣。当然现在大部分的数据库都已经支持了这种思想，所以对于大多数据库使用者来说是没有感知的，但是倒退到数据库的远古时代，抛开服务器性能来说，数据自身的性能也是比较差。
MVCC的思想化实现是如何运作的
MVCC引入了快照的思想，通过多个数据快照版本为不同事务中读取时提供数据基础，至于读取到哪一个数据版本需要根据不同的事务隔离级别来决定。
- 读已提交Read Committed——该事务隔离级别的特性是可以读取到其他事务已经提交的数据，就是说一个事务T在读取数据的时候，如果其他事务对同一数据进行修改如果没有提交，那么事务T读取到的数据版本就不会改变（MVCC的快照数据），对于MySQL来说是undo log中的数据。如果其他事务修改了该段数据并提交，那么事务T读取到的数据版本就会发生变化（MVCC的快照数据）。
- 可重复读Repeatable Read——该事务隔离级别的特性是可以同一个事务内读取的数据段都是不变的（MVCC的快照数据），就是说一个事务T在多次读取同一数段据的时候，其他事务对相同数据进行修改删除等操作，不管是否提交。这个事务T内读取该段数据版本是不会变化的（MVCC的快照数据）。
总结
MVCC的出现是为了解决数据库中使用锁机制导致的读写不能并行的问题，通过数据快照版本的控制让读写和写读操作可以并发操作，这样可以大大提高数据库的并发效率。
虽然MVCC提高数据库的并发效率，但是MVCC也是有缺点的。
- 维护一个快照版本是有空间成本与时间成本的
- 查询数据时需要根据事务隔离级别来比对数据版本，增加了数据查询的时间成本
本文参考了一些资料中的思想与概念，如果有不对的地方小伙伴可以留言交流。
