深入详解MYSQL的MVCC机制

参考资料:

参考视频(注意第二个视频关于幻读的讲解是错误的,详情见本文)

redoLog的结构详解

参考资料


学习内容:

1. MVCC要解决的问题

MVCC要解决的问题是,在不产生脏读等数据库问题的前提下,数据库的查询语句和更改语句不相互阻塞的情况;

在InnoDB中,MVCC仅仅存在于已提交读和可重复读两个隔离级别。

2. MVCC的实现机制

MVCC的实现完全依赖于undolog链表和ReadView两大板块

3. UndoLog链表

(1)InnoDB数据库中的每一行,都有三个隐藏字段

  1. 事务ID(DB_TRX」D):增删改都会默认开启事务,数据行每参与一次事务,就会更新改行的事务ID.
  2. 回滚指针():指向旧版本的数据
  3. Row_ID:  当InnoDB表没有规定主键,并且找不到非空列来构建聚簇索引,那么就会使用Row_ID作为改行的唯一标识,来构建聚簇索引

(2) Undo_Log的结构如下

        数据库中的数据,在参与事务前(修改前),都会记录一个undo_log(包括原先的回滚指针和事务ID)

        然后事务修改数据,并且更新隐藏的事务ID和回滚指针(回滚指针指向undo_log中的上一个版本数据)

        就这样不断地更新,就生成了undo_log版本链表

        其实undo_log版本链的结构要复杂的多,关于undo_log的详细介绍见前面的笔记

(3) 当前读和快照读

  1. 不加锁的select就是快照读(读取MVCC中undo_log的版本链中的数据)
  2. 加锁的select 和增删改等其他语句就是当前读(直接读取数据库表中的数据)

(4)Read view表

① ReadView作用

        当相同的数据被很多事务操作的时候,UndoLog就会变得错综复杂且冗长,那么在进行select快照读的时候,往往很难判断应该读取哪个快照;

        所以在进行select快照读的时候,会生成一个readview,用来帮助确定是需要读取哪个undoLog快照

②ReadView的结构

        ReadView其实是事务ID的集合,其中包括当前正在执行未提交的事务ID列表,创建ReadView的事务ID等

③ ReadView生成时机

        RC(已提交读):ReadView在RC(已提交读)隔离级别下,每进行一次select快照读,就会生成一个ReadView

        RR(可重复读): ReadView在RR(可重复读)隔离级别下,每一个事务只有一个readView,在第一次进行select快照读时生成,后续的快照读,共享这一份readView

④ ReadView的执行逻辑

        当我们进行select快照读时,就会使用ReadView,顺着当前数据以及它所连接的UndoLog版本链,进行事务ID的比对,选出对应的数据版本并返回;

        具体的对比逻辑是:

顺着当前数据以及UndoLog版本链往下找,

  1. 如果事务ID小于readView的事务ID列表中的最小值,表示该数据已提交,那么就进行返回;
  2. 如果事务ID大于readView的事务ID列表中的最大值,该数据不可以返回,继续寻找;
  3. 如果事务ID大于等于readView的事务ID列表中的最小值且小于等于事务ID列表中的最大值:
    1. 如果事务ID在readView的事务ID列表中,且事务ID等于创建readView的事务ID,那么就进行返回,否则不可以返回,继续寻找
    2. 如果事务ID不在readView的事务ID列表中,那么就进行返回;

⑤ InnoDb的MVCC在RR(可重复读)隔离级别下的幻读问题

结论:InnoDB在RR隔离级别下,仅仅解决了部分幻读问题,并没有解决全部

下面将通过举例来说明(数据库在RR隔离级别下)

假设数据库中有原始数据

1)发生幻读的情况

具体步骤如下:

 首先,事务202会进行一次select快照读,并生成ReadView

查询结果为:

然后事务201进行一次数据插入,并提交,此时的数据库为:

然后事务202进行了一次数据更新,这时就会产生UndoLog

最后事务202进行select快照读,因为此时隔离级别为RR(可重复读),所以共用着一份readView

readView会顺着数据和redoLog链进行查询

因为202属于区间[201,202],且202为当前事务ID,

所以查询到的数据为:

此时便发生了幻读

2) 解决幻读的情况

具体步骤如下:

  1. 首先,事务202会进行一次select快照读,并生成ReadView

查询结果为:

b.然后事务201进行一次数据插入,并提交,此时的数据库为:

 然后事务202进行了一次数据更新,这时就会产生UndoLog

  1. 最后事务202进行select快照读,因为此时隔离级别为RR(可重复读),所以共用着一份readView

e.readView会顺着数据和redoLog链进行查询
因为202属于区间[201,202],且202为当前事务ID,201虽然属于这个区间,但是不等于当前事务ID,所以只显示202的数据

所以得到的结果为:

并没有发生幻读


### 回答1: MySQLMVCC(Multi-Version Concurrency Control)机制是通过为每个读操作创建一个版本(Version)并保留旧版本来实现的。这个机制允许多个事务同时访问同一数据行,同时确保它们不会互相干扰或产生冲突。 MVCCMySQL中的实现方式是,对于每一行数据,在表中存储一个隐藏的系统版本号(system versioning),并将每个操作(包括SELECT查询)的时间戳与该行的版本号进行比较。当读取一行数据时,MySQL会根据当前的事务时间戳和行的版本号来决定该行是否可见。如果行的版本号早于当前事务的时间戳,则说明该行是旧版本,不可见;如果行的版本号晚于当前事务的时间戳,则说明该行是新版本,可见。 在MVCC机制下,读操作不会阻塞写操作,写操作也不会阻塞读操作。因此,MVCC机制可以提高并发性能和可伸缩性,使得多个事务可以同时访问同一数据库而不会产生锁定和阻塞问题。 但是,MVCC机制也有一些限制。例如,如果事务A在读取某个数据行的同时,事务B修改了该行的值,那么事务A在提交时就会检测到该数据行已经被修改,从而回滚该操作。此外,MVCC机制也会占用更多的存储空间来存储旧版本的数据行。 ### 回答2: MySQLMVCC(多版本并发控制)是一种用于处理并发访问的机制MVCC是通过在数据库的各种操作(如事务的开启、读取和写入)中使用隐藏的时间戳来实现的。 MVCC的主要目标是避免读取和写入操作之间的冲突,从而提高数据库的并发性能和资源利用率。它通过在内部为每个事务提供一个唯一的时间戳来实现。每个事务在开始时都会获得一个时间戳,并且事务中的每个操作都使用这个时间戳。 当一个事务读取数据时,它只能读取它开始时间之前的数据版本。这样可以避免读取到其他事务正在写入或修改的数据,从而保证读取操作的一致性和隔离性。 当一个事务写入数据时,它会创建一个新的数据版本,并将其与事务的时间戳关联。这个新版本的数据不会立即覆盖旧的数据,而是以一种类似于快照的方式存在。其他事务在读取数据时仍然可以访问旧版本的数据。 MVCC还使用了回滚段(undo log)来处理事务的回滚操作。当一个事务被回滚时,数据库会使用回滚段将所有该事务做出的修改逆转回去,从而恢复到事务开始之前的状态。 需要注意的是,MVCC机制对于并发性能和资源利用率的提升是有限的。在高并发的情况下,数据库可能会出现锁等待和资源竞争的问题。为了进一步优化并发性能,可以考虑使用其他技术,如乐观并发控制(Optimistic Concurrency Control)和分布式数据库。 ### 回答3: MySQLMVCC(Multi-Version Concurrency Control)机制是一种并发控制技术,用于处理数据库中的读写冲突。它允许多个事务同时读取数据库,同时也使得读写冲突被有效地解决。 MVCC机制基于以下两个重要的概念:版本号和快照。 首先,每个表中的每个行都有一个版本号。当一个事务对某行进行修改时,会为该事务创建一个新的版本,并将旧版本标记为过期。这样,读取该行的事务会读取到未过期的版本,而不会受到写用户的影响。同时,这也避免了仅读用户被阻塞的情况。 其次,为了实现读取未过期版本的行,MVCC机制通过创建快照来实现。快照是数据库在某个时间点的一个镜像,其中包含了未过期的行版本。当一个读取事务开始时,会生成一个当前的数据库快照,并基于这个快照来读取数据行。这样,读取事务不会看到在其开始时(即快照生成时)已提交的写入事务,从而实现了读写并发。 MVCC机制对于提高数据库的并发性能非常重要。它允许多个事务同时进行读操作,提高了数据库的并发处理能力。此外,它也避免了读写冲突和阻塞的情况,提高了数据库的效率和稳定性。 总之,MySQLMVCC机制通过使用版本号和快照来实现读写并发控制和冲突的解决。它是提高数据库并发性能和减少阻塞的关键技术之一,并且在实际的数据库应用中扮演着非常重要的角色。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

PH = 7

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值