搞懂这个图就可以了
mvcc核心4个东西(这些都是事务字段和readview的东西,看完下面,这个就懂了,一开头看这四个东西,很容易懵逼)
-
1、事务版本号
-
2、表的隐藏列。
-
3、undo log
-
4、 read view
事务的版本号:每次开启都会获得自增长的事务id,可以根据事务的id判断,事务的执行顺序,它是自增的,有点像主键。
表的隐藏列:会为我们添加三个隐藏字段
-
DB_TRX_ID: 事务ID,记录的是当前事务在做INSERT或UPDATE语句操作时的事务ID;
-
DB_ROLL_PTR:指向上一个版本数据在undo log 里的位置指针,回滚指针,通过它可以将不同的版本串联起来,形成版本链。;
-
DB_ROW_ID: 隐藏ID ,当创建表没有合适的索引作为聚集索引时,会用该隐藏ID创建聚集索引;
结合上图可以看到,DB_TRX_ID,DB_ROLL_PTR,这两个东西用到了让事务指向了undolog
假如说有个新数据要修改,把张三改成李四,可以看到事务id变成了104(有点像主键自增长1),上个版本数据的行号变为了103
比如李四的事务表:它的DB_ROLL_PTR就变为了103
read view 就是没有提交的事务有哪些,就是一个整体的事务的状态表,每次事务开启都有一个readview。
我的理解,read view 是这样的,先给你们看看原本比较笼统的说法。
Read view 的几个重要属性
-
trx_ids: 当前系统活跃(未提交)事务版本号集合。
-
low_limit_id: 创建当前read view 时“当前系统最大事务版本号+1”。
-
up_limit_id: 创建当前read view 时“系统正处于活跃事务最小版本号”
-
creator_trx_id: 创建当前read view的事务版本号;
-
我的理解的read view(不官方版本),就是一个数据快照,看还有哪些事务没有提交,可能有错误。
trx_ids:就是当前有哪些事务还没有提交,比如上图,a,b双方都有id,但是都没提交,那么它们就是一个集合,根据他们的事务id就是102,103.
low_limit_id:事务id大于low_limit_id,说明它是在创建read view之后创建的,那么肯定是没有提交过的,所以数据不显示。
up_limit_id:当前的的事务id小于up_limit_id。以下可能有错误,说明事务已经提交过?所以它的的数据是可以显示的。
ps:可能有种情况,事务id在low_limit_id和up_limit_id之间,则说明刚刚创建没多久的事务还没有提交的事务,所以要在trx_ids中匹配,没有的话,说明已经提交了,数据不显示。存在,只有自己能看到,别人不能看见,因为这是自己创建的事务。
creator_trx_id:这东西似乎是用来区别是不是自己生成的事务,一般来说是最新的那个事务id,可以看第一张图,另外一个查询的人,生成了事务id,说明是根据最后一个开启事务id,它就是 creator_trx_id。
ps:说明如果事务id,不和 creator_trx_id相等,说明这是外星球来的人,不是自己人。
补充:mvcc只在读已提交读未提交中使用