【MySQL技术内幕】48-事务的实现之purge

作者简介:大家好,我是码炫码哥,前中兴通讯、美团架构师,现任某互联网公司CTO,兼职码炫课堂主讲源码系列专题


代表作:《jdk源码&多线程&高并发》,《深入tomcat源码解析》,《深入netty源码解析》,《深入dubbo源码解析》,《深入springboot源码解析》,《深入spring源码解析》,《深入redis源码解析》等


联系qq:184480602,加我进群,大家一起学习,一起进步,一起对抗互联网寒冬

delete和 update操作可能并不直接删除原有的数据。例如,对上一小节所产生的表t执行如下的SQL语句:
DELETE FROM t WHERE a=1;

表t上列a有聚集索引,列b上有辅助索引。对于上述的 delete操作,通过前面关于undo log的介绍已经知道仅是将主键列等于1的记录delete flag设置为1,记录并没有被删除,即记录还是存在于B+树中。其次,对辅助索引上a等于1,b等于1的记录同样没有做任何处理,甚至没有产生 undo log。而真正删除这行记录的操作其实被“延时”了,最终在 purge操作中完成。

purge用于最终完成 delete和 update操作。这样设计是因为 InnoDB存储引擎支持MVCC,所以记录不能在事务提交时立即进行处理。这时其他事物可能正在引用这行,故 InnoDB存储引擎需要保存记录之前的版本。而是否可以删除该条记录通过 purge来进行判断。若该行记录已不被任何其他事务引用,那么就可以进行真正的 delete操作。可见, purge操作是清理之前的 delete和 update操作,将上述操作“最终”完成。而实际执行的操作为 delete操作,清理之前行记录的版本。

在前一个小节中已经介绍过,为了节省存储空间, InnoDB存储引擎的 undo log设计是这样的:一个页上允许多个事务的 undo log存在。虽然这不代表事务在全局过程中提交的顺序,但是后面的事务产生的 undo log总在最后。此外, InnoDB存储引擎还有个 history列表,它根据事务提交的顺序,将 undo

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值