MySQL MVCC机制解析

最新推荐文章于 2024-09-30 08:00:00 发布

Kieran_s

最新推荐文章于 2024-09-30 08:00:00 发布

阅读量249

点赞数

分类专栏： mysql 文章标签： mysql 算法

本文链接：https://blog.csdn.net/Kieran_s/article/details/119924460

版权

mysql 专栏收录该内容

8 篇文章 0 订阅

订阅专栏

1、MVCC（multi version concurrent control）机制

多版本并发控制机制，专门控制多个事物并发运行的时候，互相之间会如何影响。

MVCC机制 = undo log多本本链条+ReadView机制

1）ReadView：执行一个事务，会生成一个ReadView

关键的四个字段

m_ids：有哪些事务在MySQL里执行还没提交
min_trx_id：m_ids里最小的值
max_trx_id：mysql下一个要生成的事务id，最大的事务id
creator_trx_id：现在事务的id

假设原来数据库有一行数据，事务id是32，他的值就是初始值，如下图所示。

此时有两个事务并发执行，事务A（id=45），事务B（id=59），事务B要更新这行数据的值，事务A要读取这行数据的值。

现在事务A直接开启一个ReadView，这个ReadView里的m_ids就包含了事务A和事务B的两个id，45和59，所以min_trx_id就是45，max_trx_id就是60，creator_trx_id是45，就是事务A本身。

事务A第一次查询这行数据，会判断当前这行数据的trx_id是否小于ReadView中的min_trx_id，此时发现txr_id是32，小于ReadView的min_trx_id，也就是45，说明事务开启之前，修改这行数据的事务早就提交了，此时可以查到这行数据，如下图所示：

事务B开始执行，将这行数据改为值B，txr_id设置为自己的id，59，同时roll_pointer指向修改之前生成的undo log，如下图所示：

这个时候事务A再次查询，此时数据行里txr_id=59，那么这个txr_id大于ReadView里的min_txr_id（45），小于ReadView中的max_trx_id（60），说明更新这条数据的事务，是跟自己差不多同时开启的，不可以查这条数据。

顺着这条数据的roll pointer顺着undo log日志链条往下找,就会找到最近的一条undo log , trx id是32,此时发现trx id=32,是小于ReadView里的min trx id (45 )的,说明这个undo log版本必然是在事务A开启之前就扶行且提交的。查询最近的那个undo log里的值好了,这就是undo log多版本链条的作用,他可以保存一个快照链条,让你可以读到之前的快照值。

通过这套ReadView + undo log 日志链条的机制可以保证事务A不会读到并发执行的事务B更新呢的值，只会读到之前的值。

此时事务A自己更新这行数据，改成值A，trx_id修改为45。

事务A 再次来查询这条数据的值，发现trx_id，与自己ReadView中的creator_trx_id是一样的，说明这行数据就是自己修改的，因此可以看到这条数据。如下图：

此时事务A执行的过程中，突然开启了事务C，这个事务的id是78，然后他更新了哪行数据的值为值C ，并且提交，如下图：

此时事务A再去查询，会发现当前数据的trx_id=78，大于自己ReadView中的max_trx_id（60），说明这条数据是事务A开启后，新的事务来更新了数据，因此看不到这条数据。如下图：

事务A会顺这undo log链条往下找，先找到值A自己修改过的那个版本，因为trx_id=45与自己ReadView中的Creator_trx_id是一样的，所以读取trx这条数据。如下图：

通过undo log+ReadView机制，保证你只能读到你事务开启之前的数据，别的提交事务更新的值，还有就是你自己事务更新的值。可以实现多个事务并发执行时候的数据隔离。

2、RC（Read Committed）基于ReadVIew的实现

核心：一个事务设置处于RC隔离级别的时候，他每次发起查询，都重新生成一个ReadView。

本质：协调多个事务并发运行的时候，并发的读写同一批数据，协调互相的可见性。

解析：

此时数据库有一条事务id=50的数据，另外活跃的两条事务，事务A（id=60）,事务B（id=70）。如下图：

当事务B发起一次update操作，更新了这条数据，把这条数据的值修改为了值B，此时数据的trx_id变为事务B的id=70，同时生成一条undo log，由roll_pointer指向trx_id=50的数据。如下图：

此刻事务A发起查询，生成一个ReadView，此时ReadView里的min_trx_id=60，max_trx_id=71，creator_trx_id=60，如下图所示：

事务A发现当前这条数据的trx_id=70，属于ReadView的事务id范围之内，说明是他生成ReadView之前就有这个活跃的事务B，事务B修改了这条数据的值，还没有提交，所以ReadView的m_id活跃事务列表里，有[60,70]两个id，所以此时根据ReadView的机制，此时事务A无法查到事务B修改的值B。

顺着链条下找，发现trx_id=50的数据，小于当前ReadView中的min_trx_id=60，说明这条数据是事务A生成ReadView之前插入的并且提交了，因此可以查到，如下图所示：