MySQL中的MVCC是怎么实现的，你们知道吗？

「这是我参与11月更文挑战的第21天，活动详情查看：2021最后一次更文挑战」

不晓得大家了解不了解MySQL的MVCC机制，这个是MySQL底层原理中比较重要的一项，它能极大的提高MySQL数据库的并发性能。MVCC广泛应用于数据库技术，像Oracle,PostgreSQL等都引入了该技术。本篇文章我们就带大家一起了解一下MySQL的MVCC机制实现原理。

什么是MVCC？

Multi-Version Concurrency Control（MVCC），翻译过来就是多版本并发控制，MVCC是为提高MySQL数据库并发性能的一个重要设计。

同一行数据发生读写请求时，会通过锁来保证数据的一致性。MVCC可以在读写冲突时，让其读数据时通过快照读，而不是当前读，快照读不必加锁。

在前边文章我们也介绍了MySQL中的锁机制，不熟悉的可以翻阅前边的文章。

InnoDB的事务

MySQL中的MVCC是在InnoDB存储引擎中得到支持的，InnoDB中最重要，也是最特殊的可谓就是事务，所以事务相关的一些设计我们必须了解。

• 行级锁 InnoDB提供了行级锁，行级锁无疑使锁的粒度更细，但是数据过多时，在高并发场景下，同一时刻会产生大量的锁，因此，InnoDB也对锁进行了空间的有效优化，使得其在并发量高的情况下，也不会因为同一时刻锁过多，而导致内存耗尽。

  • 排他锁
  • 共享锁。

• 隔离级别

  • READ_UNCOMMITTED：脏读
  • READ_COMMITTED：读提交
  • REPEATABLE_READ：重复读
  • SERIALIZABLE：串行化

• redo log

  redo log 就是保存执行的SQL语句到一个指定的Log文件，当Mysql执行recovery时重新执行redo log记录的SQL操作即可。当客户端执行每条SQL（更新语句）时，redo log会被首先写入log buffer；当客户端执行COMMIT命令时，log buffer中的内容会被视情况刷新到磁盘。redo log在磁盘上作为一个独立的文件存在，即InnoDB的log文件。

• undo log

  与redo log相反，undo log是为回滚而用，具体内容就是将事务影响到的行的原始数据行写入到到undo buffer，在合适的时间把undo buffer中的内容刷新到磁盘。undo buffer与redo buffer一样，也是环形缓冲，但当缓冲满的时候，undo buffer中的内容会也会被刷新到磁盘；与redo log不同的是，磁盘上不存在单独的undo log文件，所有的undo log均存放在主ibd（表空间）数据文件中，即使客户端设置了每表一个数据文件也是如此。

行更新的过程

InnoDB为每行记录都实现了三个隐藏字段：

• 隐藏的ID
• 6字节的事务ID（DB_TRX_ID）
• 7字节的回滚指针（DB_ROLL_PTR）

行更新的过程

1. 数据库新增一条数据，该条数据三个隐藏字段，只有ID有值

2. T1修改该条数据，开启事务，记录read_view

   • 排它锁锁定该行数据
   • 记录redo log
   • 将该行数据写入undo log
   • 将修改值写入该条数据，填写事务Id，根据undo log记录位置填写回滚指针

3. T2修改该条数据，开启事务，记录read_view

   • 排它锁锁定该行数据
   • 记录redo log
   • 将该行数据写入undo log
   • 将修改值写入该条数据，填写事务Id，通过回滚指针将undo log 的两条记录连接起来（版本链）

4. 事务提交，记录read_view

   • 正常提交
   • 如果触发回滚，需要根据回滚指针找到undo log对应记录进行回滚

注意：

• InnoDB中存在purge线程，它负责查询，并清理那些无效的undo log。
• 上述过程描述的是UPDATE事务的过程，当INSERT时，原始的数据并不存在，所以在回滚时把insert丢弃即可

MVCC的基本特征

• 每行数据都存在一个版本，每次更新数据时都更新该版本。
• 修改时拷贝出当前版本随意修改，各个事务之间无干扰。
• 保存时比较版本号，如果成功提交事务，则覆盖原记录；如果失败回滚则放弃拷贝的数据。

InnoDB如何实现MVCC？

MVCC则是建立在undo log 之上的。

undo log 中记录的数据就是MVCC中的多版本。

通过回滚指针形成版本链。

通过事务ID可以查找到read-view上的记录

read-view记录：

• m_ids:表示活跃事务id列表
• min_trx_id:活跃事务中的最小事务id
• max_trx_id:已创建的最大事务id
• creator_trx_id:当前的事务id

版本链比对规则：

1. 如果 trx_id < min_trx_id，表示这个版本是已提交的事务生成的,这个数据是可见的；

2. 如果 trx_id > max_trx_id，表示这个版本是由将来启动的事务生成的,是肯定不可见的。

3. 如果 min_trx_id <= trx_id <= max_trx_id，那就包括两种情况

   • 若row的trx_id在m_ids数组中，表示这个版本是由还没提交的事务生成的,不可见,当前自己的事务是可见的。

   • 若row的trx_id不在m_ids数组中，表示这个版本是已经提交了的事务生成的,可见

MySQL的InnoDB实现MVCC，就是在隔离级别为读已提交和可重复读，基于乐观锁理论，通过事务ID和read-view的记录进行比较判断分析数据是否可见，从而使其大部分读操作可以无需加锁，从而提高并发性能。

但是在写数据的时候，InnoDB还是需要加排它锁的。

总结，就是用乐观锁代替悲观锁，从而提高并发性能，这就是MVCC。