MySQL多版本并发控制MVCC深入学习

mvcc

mvcc（multi-version concurrency control），即多版本并发控制。是 innodb 实现事务并发与回滚的重要功能。锁机制可以控制并发操作,但是其系统开销较大,而mvcc可以在大多数情况下代替行级锁,使用mvcc,能降低其系统开销.

具体实现是在数据库的每一行中，额外添加三个字段：

1. db_trx_id : 记录插入或更新该行的最后一个事务的事务id
2. db_roll_ptr : 指向改行对应undolog 的指针
3. db_row_id : 单调递增的id，他就是auto_increment的主键id

快照读

像不加锁的select操作就是快照读，快照读的出现是基于提高并发性能的考虑，快照读的实现是基于多版本并发控制，即mvcc。可以认为 mvcc 是行锁的一个变种，在很多情况下，避免了加锁操作，降低了开销；既然是基于多版本，即快照读可能读到的并不一定是数据的最新版本，而有可能是之前的历史版本

当前读

读取的是当前的数据，不需要通过undo log回溯到事务开启前的状态。读取的是记录的最新版本，读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加锁。

数据库并发场景有三种，分别为：

• 读-读：不存在任何问题，也不需要并发控制
• 读-写：有线程安全问题，可能会造成事务隔离性问题，可能遇到脏读，幻读，不可重复读
• 写-写：有线程安全问题，可能会存在更新丢失问题，比如第一类更新丢失，第二类更新丢失

说白了 mvcc 就是为了实现读-写冲突不加锁，而这个读指的就是快照读, 而非当前读，当前读实际上是一种加锁的操作，是悲观锁的实现

mvcc的出现就是大佬们不满意用悲观锁去解决读-写冲突问题，所以有两个方案：

• mvcc + 悲观锁
  mvcc解决读写冲突，悲观锁解决写写冲突
• mvcc + 乐观锁
  mvcc 解决读写冲突，乐观锁解决写写冲突

 

mvcc实现原理

三个隐藏字段

• db_trx_id
  6 字节，最近修改(修改/插入)事务 id：记录创建这条记录/最后一次修改该记录的事务 id
• db_roll_ptr
  7 字节，回滚指针，指向这条记录的上一个版本（存储于 rollback segment 里）
• db_row_id
  6 字节，隐含的自增 id（隐藏主键），如果数据表没有主键，innodb 会自动以db_row_id产生一个聚簇索引

版本链 / undo log

因为undo log会记录事务前老版本数据，然后行记录中回滚指针会指向老版本位置，如此形成一条版本链。read view 会一直遍历链表的db_trx_id，直到找到满足特定条件的 db_trx_id。那么这个db_trx_id所在的旧记录就是当前事务能看见的最新”老版本“

read view

是事务开启时，当前所有活跃事务（还未提交的事务）的一个集合。或者说read view 就是事务进行快照读操作的时候生产的读视图 (read view)，在该事务执行的快照读的那一刻，会生成数据库系统当前的一个快照，记录并维护系统当前活跃事务的 id

三个read view重要结构：

• trx_list（名称我随意取的）
  一个数值列表
  用于维护 read view 生成时刻系统 正活跃的事务 id 列表
• up_limit_id
  是 trx_list 列表中事务 id 最小的 id
• low_limit_id

readview 生成时刻系统尚未分配的下一个事务 id ，也就是 目前已出现过的事务 id 的最大值 + 1

为什么是 low_limit ? 因为它也是系统此刻可分配的事务 id 的最小值

mvcc实现的整体流程：

总结

• 应对高并发事务, mvcc比单纯的加锁更高效
• mvcc只在 读已提交 和 可重复读 两个隔离级别下工作
• 读已提交隔离级别下，会在每次快照读（查询）都生成一个read view，可重复读只在事务开始时生成一个read view，以后每次查询都用这个read view，以此实现不同隔离级别。

参考：

【mysql笔记】正确的理解mysql的mvcc及实现原理_（推荐）

mysql · 引擎特性 · innodb 事务系统 (taobao.org)

mvcc详解 - 简书 (jianshu.com)

到此这篇关于mysql多版本并发控制mvcc深入学习的文章就介绍到这了。希望对大家的学习有所帮助，也希望大家多多支持服务器之家。

原文链接：https://www.cnblogs.com/CJ-cooper/p/15610508.html