本文主要是介绍mysql的MVCC多版本并发控制机制，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

MVCC多版本并发控制机制

• 全英文名：Multi-Version Concurrency Control
• MVCC不会通过加锁互斥来保证隔离性，避免频繁的加锁互斥。
• 而在串行化隔离级别为了保证较高的隔离性是通过将所有操 作加锁互斥来实现的
• Mysql在读已提交和可重复读隔离级别下都实现了MVCC机制。
• 锁机制可以控制并发操作,但是其系统开销较大,而MVCC可以在大多数情况下代替行级锁,使用MVCC,能降低其系统开销.

MVCC实现方式：版本链（undo日志）

• 在InnoDB引擎表中，它的聚簇索引记录中有两个必要的隐藏列：

trx_id

这个id用来存储的每次对某条聚簇索引记录进行修改的时候的事务id。

roll_pointer

每次对哪条聚簇索引记录有修改的时候，都会把老版本写入undo日志中。这个roll_pointer就是存了一个指针，它指向这条聚簇索引记录的上一个版本的位置，通过它来获得上一个版本的记录信息。(注意插入操作的undo日志没有这个属性，因为它没有老版本)

MVCC查询的方式：一致性视图read-view

• 已提交读和可重复读的区别就在于它们生成ReadView的策略不同。已提交读是每次查询都会生成新的read-view，可重复读所有查询都使用第一次查询的时候生成read-view。
• 由执行查询时所有未提交事务id数组（数组里最小的id为min_id）和已创建的最大事务id（max_id）
• 事务里的任何sql查询结果需要从对应 版本链里的最新数据开始逐条跟read-view做比对从而得到最终的快照结果。

版本链比对规则：

• 如果 row 的 trx_id 落在绿色部分( trx_id<min_id )，表示这个版本是已提交的事务生成的，这个数据是可见的；
• 如果 row 的 trx_id 落在红色部分( trx_id>max_id )，表示这个版本是由将来启动的事务生成的，是不可见的(若 row 的 trx_id 就是当前自己的事务是可见的）；
• 如果 row 的 trx_id 落在黄色部分(min_id <=trx_id<= max_id)，那就包括两种情况
  • 若 row 的 trx_id 在视图数组中，表示这个版本是由还没提交的事务生成的，不可见(若 row 的 trx_id 就是当前自己的事务是可见的)；
  • 若 row 的 trx_id 不在视图数组中，表示这个版本是已经提交了的事务生成的，可见。

这篇关于mysql的MVCC多版本并发控制机制的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！