采得百花成蜜后,为谁辛苦为谁甜。这篇文章主要讲述#yyds干货盘点# MySQL RC事务隔离级别的实现相关的知识,希望能为你提供帮助。
Read Committed,事务运行期间,只要别的事务修改数据并提交,即可读到人家修改的数据,所以会有不可重复读、幻读问题。
ReadView机制基于undo log版本链条实现的一套读视图机制,事务生成一个ReadView:
- 若为事务自己更新的数据,自己可以读到
- 或在你生成ReadView之前提交的事务所修改的值,也可读到
- 但若你生成ReadView时,就已经活跃的事务,但如果它在你生成ReadView之后修改的数据并提交了,此时你读不到
- 或你生成ReadView以后再开启的事务修改了数据,还提交了,也读不到
数据库里有一行数据,是事务id=50的一个事务,很久以前就插入的,当前活跃事务:
- 事务A(id=60)
- 事务B(id=70)
这时,事务A要发起一次查询操作,就会生成一个ReadView
这时事务A发起查询,发现当前这条数据的trx_id=70。即属于ReadView的事务id范围之间,说明是他生成ReadView之前就有这个活跃的事务,是这个事务修改了这条数据的值,但此时事务B还没提交,所以ReadView的m_ids活跃事务列表里,有[60, 70]两个id,此时根据ReadView机制,事务A无法查到事务B修改的值b。
接着就顺着undo log版本链条往下查找,就会找到一个原始值,发现其trx_id是50,小于当前ReadView里的min_trx_id,说明是他生成ReadView之前,就有一个事务插入了这个值并且早就提交了,因此可以查到这个原始值。
接着,假设事务B提交,提交了就说明事务B不会活跃于数据库里了。事务A下次再查询,就可以读到事务B修改过的值了。那到底是怎么让事务A能够读到提交的事务B修改过的值呢?
让事务A下次发起查询,再生成一个ReadView,数据库内活跃的事务只有事务A,因此:
- min_trx_id是60
- mac_trx_id是71
- m_ids=60,事务B的id=70不会出现在m_ids活跃事务列表
推荐阅读
- Debiasing word embeddings | 浅谈词嵌入除偏 #yyds干货盘点#
- 利用反射生成 MyBatisPlus中QueryWrapper动态条件#yyds干货盘点#
- #yyds干货盘点# 美团二面面经,最后竟然有惊喜()
- #yyds干货盘点# Kubernetes 怎样对业务数据进行持久化存储((10))
- 设计模式15--从审批流中学习责任链模式
- Python设置为检查字符串是否为panagram(全字母短句)
- Python集合操作(联合,交集,差分和对称差分)
- Python设置和检索Tkinter变量的值
- Python集合update()函数用法示例