【MySQL】MVCC终于懂了通透

最新推荐文章于 2024-06-22 19:36:08 发布

smartaconf

最新推荐文章于 2024-06-22 19:36:08 发布

阅读量774

点赞数 1

分类专栏： MySQL 文章标签： mysql

本文链接：https://blog.csdn.net/weixin_45919793/article/details/124163339

版权

MySQL 专栏收录该内容

20 篇文章 0 订阅

订阅专栏

MVCC

MVCC解决的是什么问题

问题：并发过程中读-写冲突，写-读冲突
两种解决方式：

加锁
MVCC

加锁会导致串行化，并发效率不高
MVCC非锁定的一致性读（不加锁，非阻塞并发快照读），写的时候才加锁

快照读

不加锁的非阻塞读
不加锁的简单的SELECT都属于快照读
快照读读的不一定是最新版本，可能是之前的历史版本
快照读的隔离级别不是串行级别，串行级别下快照读会退化为当前读

当前读

读取的记录是最近的版本，读取时加锁

事务的四种隔离级别
存在三种并发问题

隔离级别	存在并发问题	解决问题
读未提交	脏读，不可重复读，幻读	无
读已提交	不可重复读，幻读	脏读
可重复读	幻读	脏读，不可重复读
串行化	无	脏读，不可重复读，幻读

InnoDB存储引擎中，在可重复读隔离级别下通过MVCC+next-key解决幻读问题

MVCC 多版本并发控制实现原理

多版本：即undo log版本链中的行记录版本
并发读-写：读读的是快照 写写的是最新版本
控制：通过ReadView并借助两个隐藏字段实现了多个版本可见性的管理

隐藏字段

trx_id：最近的一次操作该行记录的事务id

说明：只有在更新数据的时候才会给事务分配事务id

roll_pointer：对某条聚簇索引记录进行更改时，会把旧的版本写入到undo日志中，这个隐藏字段相当于是一个指针，通过它能够找到该记录修改前的行记录。

Undo Log 版本链

对一条记录每次更新后，都会将引旧值放到一条undo日志中，就算是该记录的一个旧版本，随着更新次数的增多，所有的版本都会被roll_pointer属性连接成一个链表，我们把这个链表称之为版本链，版本链的头节点就是当前记录最新的值。

MVCC中的多版本，就是指的undo日志中的多个版本数据

ReadView

在MVCC机制中，多个事务对同一个行记录进行更新会产生多个历史快照，这些历史快照保存在Undo Log里。如果一个事务想要查询这个行记录，需要读取哪个版本的行记录呢？这时就需要用到ReadView了，它帮我们解决了行的可见性问题。

ReadView就是事务A在使用MVCC机制进行快照读操作时产生的读视图。当事务启动时，会生成数据库系统当前的一个快照，InnoDB为每个事务构造了一个数组，用来记录并维护系统当前活跃事务的ID(“活跃”指的就是，启动了但还没提交）

说明：ReadView与单个事务对应
也就是一个事务对应一个Read View

设计思路

使用READ UNCOMMITTED隔离级别的事务，由于可以读到未提交事务修改过的记录，所以直接读取记录的最新版本就好了。
使用SERIALIZABLE隔离级别的事务，InnoDB规定使用加锁的方式来访问记录。

使用READ COMMITTED和REPEATABLE READ隔离级别的事务，都必须保证读到已经提交了的事务修改过的记录。
假如另一个事务已经修改了记录但是尚未提交，别的事物是不能直接读取最新版本的记录的，核心问题就是需要判断一下版本链中的哪个版本是当前事务可见的，这是ReadView要解决的主要问题。

Read View字段内容

1.creator_trx_id,创建这个Read View的事务ID.

再次说明：只有在对表中的记录做改动时(执行NSERT、DELETE、UPDATE这些语句时)才会为事务分配事务id,否则在一个只读事务中的事务id值都默认为0.

2.trx_ids,表示在生成ReadViewl时当前系统中活跃的读写事务的事务id列表。
3.up_limit_id,活跃的事务中最小的事务ID.
4.low_limit_id,表示生成ReadView时系统中应该分配给下一个事务的id值。

low_limit_id是系统最大的事务id值，这里要注意是系统中的事务id,需要区别于正在活跃的事务D。

ReadView规则

有了这个ReadView，这样在访问某条记录时，只需要按照下边的步骤判断记录的某个版本是否可见。
如果被访问版本的trx_id属性值与ReadView中的 creator_trx_id 值相同，意味着当前事务在访问
它自己修改过的记录，所以该版本可以被当前事务访问。
如果被访问版本的trx_id属性值小于ReadView中的 up_limit_id 值，表明生成该版本的事务在当前事务生成ReadView前已经提交，所以该版本可以被当前事务访问。
如果被访问版本的trx_id属性值大于或等于ReadView中的 low_limit_id 值，表明生成该版本的事务在当前事务生成ReadView后才开启，所以该版本不可以被当前事务访问。
如果被访问版本的trx_id属性值在ReadView的 up_limit_id 和 low_limit_id 之间，那就需要判断一下trx_id属性值是不是在 trx_ids 列表中。
1. 如果在，说明创建ReadView时生成该版本的事务还是活跃的，该版本不可以被访问。
2. 如果不在，说明创建ReadView时生成该版本的事务已经被提交，该版本可以被访问。

MVCC整体操作流程

了解了这些概念之后，我们来看下当查询一条记录的时候，系统如何通过MVCC找到它：

首先获取事务自己的版本号，也就是事务 ID；
获取 ReadView；
查询得到的数据，然后与 ReadView 中的事务版本号进行比较；
如果不符合 ReadView 规则，就需要从 Undo Log 中获取历史快照；
最后返回符合规则的数据。

说明：

如果到最后都没有满足条件的版本，说明该事务开始执行之前就没有提交的版本
查找到的可能是多个记录，那么每一条记录都要根据ReadView规则判断可见性，找到可见的版本
存在这样一种情况，首先我么知道：事务开始时并没有真正的分配事务ID，直到第一次更新数据的时候才会分配，所以首先readview中的creator_trx_id=0，是那么是不是我们更新完该条记录，再select时，结果是不是连自己更新的记录也查找不到？很明显，不是的，因为在更新的时候，分配的事务id同时会给ReadView字段creator_trx_id重新赋值，这样便可以查找的自己的更新了。