MySQL的高并发处理技术MVCC
最近五一放假，除了带小孩到处转转外，还看了几页《高性能MySQL》。另外家里还有一本《高可用MySQL》，这都是以前在 CSDN 写作时送的书。前前后后大概 40 多本，之前搬家还扔掉一些，可惜了。。。
我们都知道，在 MySQL 中有非常多的锁。比如：共享锁，排它锁；表锁，行锁；读锁，写锁等。这些锁在处理数据时，往往会降低 MySQL 系统的并发处理能力。最早的数据库系统，只有读读之间可以并发，读写，写读，写写都要阻塞。引入多版本之后，只有写写之间相互阻塞，其他三种操作都可以并行，这样大幅度提高了InnoDB的并发度。多版本处理技术也就是我们今天要说的 MVCC。
MVCC 简单的就是说，在 InnoDB 中，会在每行数据后添加两个额外的隐藏的值来实现 MVCC，这两个值一个记录这行数据何时被创建，另外一个记录这行数据何时过期（或者被删除）。 在实际操作中，存储的并不是时间，而是事务的版本号，每开启一个新事务，事务的版本号就会递增。每行数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 “version” 字段来实现。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。
看到这里，我相信很多人会想起 CAS 操作。这个 MVCC 不就是和 CAS 操作有些类似吗？其实程序世界里的很多东西都是类似的，如果你看过《UNIX网络编程》你会发现，Java 中的并发编程模型其实也都是参考操作系统底层中的一些并发编程模型。
大道至简，我想起了我前面有文章中写过这些话。MVCC 在 MySQL 默认事务隔离级别下的多版本处理逻辑如下：
- SELECT 时，读取创建版本号<=当前事务版本号，删除版本号为空或>当前事务版本号。
- INSERT 时，保存当前事务版本号为行的创建版本号
- DELETE 时，保存当前事务版本号为行的删除版本号
- UPDATE 时，插入一条新纪录，保存当前事务版本号为行创建版本号，同时保存当前事务版本号到原来删除的行
通过 MVCC，虽然每行记录都需要额外的存储空间，更多的行检查工作以及一些额外的维护工作，但可以减少锁的使用，大多数读操作都不用加锁，读数据操作很简单，性能很好，并且也能保证只会读取到符合标准的行，也只锁住必要行。
总的来说，MVCC 有下面几个特点：
- 每行数据都存在一个版本，每次数据更新时都更新该版本
- 修改时 Copy 出当前版本, 然后随意修改，各个事务之间无干扰
- 保存时比较版本号，如果成功(commit)，则覆盖原记录, 失败则放弃 copy(rollback)
- 就是每行都有版本号，保存时根据版本号决定是否成功，听起来含有乐观锁的味道, 因为这看起来正是，在提交的时候才能知道到底能否提交成功