概述
mvcc(Multi-Version Concurrency Control):多版本并发控制。
概括的说就是过去的可见,现在正在进行中的不可见,未来的不可见。
实现原理概述
mysql
的表结构除了我们自定义的列外,还有一些隐藏列:
DB_TRX_ID
:6个byte
.记录最后一次操作这条记录的事务ID
;DB_ROLL_PTR
:7个byte
;回滚指针,指向这条记录的上一个版本数据;且上一个版本还能找到上上个版本的数据,就靠这个指针来寻址。DB_ROW_ID
:6个byte
;隐藏的自增id
。(只有当前表没有设置id
的时候,mysql
会使用这个隐藏的自增id
,这个id
是所有没有id
的表共用的)。Info flags
:4个byte
。包含删除标识等数据记录状态。
mysql
的每个写操作都会生成undo log
,其对应着一个版本的数据,这个数据版本就在表数据列的隐藏字段中,其实就是事务id
。当前最新的行数据版本号中保存的是最后一个操作该行的数据id
。
在每个事务开启的时候都会生成一个readView。mvcc
就依赖readView
和undo log
进行多版本控制。
readview的几个关键值:
up_limit_id
:当前已经提交的事务号 + 1
,事务号 < up_limit_id
的版本数据,对于当前Read View
都是可见的。理解起来就是创建Read View
视图的时候,之前已经提交的事务对于该事务肯定是可见的。
low_limit_id
:当前最大的事务号 + 1
,事务号 >= low_limit_id
的版本数据,对于当前Read View
都是不可见的。未来创建的事务对于该事务肯定是不可见的。
trx_ids
:为活跃事务id
列表,即Read View
初始化时当前未提交的事务列表(即已经begin
但是还未commit
的事务)。即记录的当前活跃事务ID
,后续即使他们提交对于本事务也是不可见的。
undo log demo图如下
假设现在有这样一条数据,其事务版本号是50,有一个事务trx_id是60的数据更新了它并提交,然后有一个trx_id=100的事务开启了更新了它,但是未提交,此时另一个事务发起select,因为trx_id=100的事务是当前活跃事务,所以其更新结果不可见,只能看到trx_id=60的数据。然后trx_id=100的事务提交了,另外有个trx_id=110的事务更新了它,但是未提交,因为select的事务的readview里保存的还是之前的数据,所以仍旧只能看到trx_id=60的数据。
ps这里就是rr和rc的区别了,rr在这个时候的readview还是不变的,但是rc这个时候的readview会重新生成,就能看到trx_id=100的强哥2了。
参考了大佬的博文后自己理解出来了一些内容
大佬博文链接
https://zhuanlan.zhihu.com/p/66791480