mysql mvcc limit_MySQL MVCC机制

行结构

每一行额外包含三个隐藏字段:

DB_TRX_ID:事务ID。行的创建时间和删除时间记录的就是此值。

DB_ROLL_PTR:指向当前记录项的undo信息。

DB_ROW_ID::随着新行插入单调递增的一个字段。当由innodb自动产生聚集索引时,聚集索引包括这个DB_ROW_ID的值,不然的话聚集索引中不包括这个值。

在insert操作时,创建时间 = DB_ROW_ID,这时,“删除时间 ”是未定义的。

在update操作时,复制新增行的“创建时间”=DB_ROW_ID,删除时间未定义,旧数据行“创建时间”不变,删除时间=该事务的DB_ROW_ID。

在delete操作时,相应数据行的“创建时间”不变,删除时间 = 该事务的DB_ROW_ID。

select操作对两者都不修改,只读相应的数据。

Read View

dulint low_limit_id; /* 事务号 >= low_limit_id的记录,对于当前Read View都是不可见的 */

dulint up_limit_id; /* 事务号 < up_limit_id ,对于当前Read View都是可见的 */

ulint n_trx_ids; /* Number of cells in the trx_ids array */

dulint* trx_ids; /* Additional trx ids which the read should

not see: typically, these are the active

transactions at the time when the read is

serialized, except the reading transaction

itself; the trx ids in this array are in a

descending order */

dulint creator_trx_id; /* trx id of creating transaction, or

(0, 0) used in purge */

关于low_limit_id,up_limit_id的理解:

up_limit_id:当前已经提交的事务号 + 1,事务号 < up_limit_id ,对于当前Read View都是可见的。理解起来就是创建Read View视图的时候,之前已经提交的事务对于该事务肯定是可见的。

low_limit_id:当前最大的事务号 + 1,事务号 >= low_limit_id,对于当前Read View都是不可见的。理解起来就是在创建Read View视图之后创建的事务对于该事务肯定是不可见的。

另外,trx_ids为活跃事务id列表,即Read View初始化时当前未提交的事务列表。所以当进行RR读的时候,trx_ids中的事务对于本事务是不可见的(除了自身事务,自身事务对于表的修改对于自己当然是可见的)。理解起来就是创建RV时,将当前活跃事务ID记录下来,后续即使他们提交对于本事务也是不可见的。

example

步骤

1

2

3

begin

begin

insert into test(score) values(1607); 假设此时事务号21

insert into test(score) values(1607); 此时事务号22

b3fcbfc81d69fc9fdaa00c22b55ea760.png 此时创建读视图,up_limit_id = 21, low_limit_id = 23 活跃事务列表为(21,22)

insert into test(score) values(1620); 事务号为23

insert into test(score) values(1621); 事务号为24

insert into test(score) values(1622); 事务号为25

select * from test; 此时的up_limit_id 为21,low_limit_id 为26,活跃事务列表为(21,22),故21,22在活跃事务列表不可见

c382954440ce724b6729fd9c596ac0b3.png

select * from test; 此时low_limit_id为26,up_limit_id 为21,活跃事务列表是(21,22) 22本事务自身可见。21的在活跃事务列表不可见。23,24不在活跃事务列表,可见

bce141384e996b9dee8ef84c315c850a.png

十一

select * from test; 事务内readview不变,low_limit_id = 23,up_limit_id = 21,活跃事务列表 (21,22)。故21自身可见,22在活跃事务列表不可见。>=23的都不可见

b3fcbfc81d69fc9fdaa00c22b55ea760.png

注意的几点:

Read View视图是在进行RR读之前创建的,而不是在事务刚begin时创建的。如果Read View视图是在事务刚begin时创建的,那么在步骤四中事务22的Read View就定下来了(up_limit_id = 21,low_limit_id = 23),那么在步骤十中就看不到3中提交的数据了,因为事务号23,24,25大于等于事务22.low_limit_id

事务内Read View一旦创建就不变化了。

在第十步中按我之前的理解,3中insert的数据是在2中begin之后插入的,按理说2是看不到3中insert插入的数据的。但是事务保证的是两次select的数据是一致的,所以Read View是在第一次select时创建的,所以3中insert的数据是在2中可以看到。

朋友们可以关注下我的公众号,获得最及时的更新:

0fa89c904956cd212a219573be0653ce.png

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值