MySQL MVCC多版本并发控制(脏读和不可重复读解决原理)

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
RDS MySQL Serverless 高可用系列,价值2615元额度,1个月
简介: MySQL MVCC多版本并发控制(脏读和不可重复读解决原理)

MySQL MVCC多版本并发控制(脏读和不可重复读解决原理)


专栏持续更新中:MySQL详解

一、MVCC概念

MVCC是多版本并发控制(Multi-Version Concurrency Control),是MySQL中基于乐观锁理论实现隔离级别的方式,用于实现已提交读和可重复读隔离级别,也经常称为多版本数据库。MVCC机制会生成一个数据请求时间点的一致性数据快照 (Snapshot), 并用这个快照来提供一定级别 (语句级或事务级) 的一致性读取。从用户的角度来看,好象是数据库可以提供同一数据的多个版本(系统版本号和事务版本号)

  • 快照读(非锁定读):读的是记录的可见版本,不用加锁。如 select做的都是快照读,会把已经commit的数据(即整表数据)生成一个快照(这就可以防止不可重复读)
  • 当前读:读取的是记录的最新版本,返回当前读的记录,并且对数据加锁。如 insert,delete,update,select…lock in share mode/for update这些操作,都是读的是最新的数据

MVCC:每一行记录实际上有多个版本,每个版本的记录除了数据本身之外,增加了其它字段(DB_ROW_ID、DB_TRX_ID、DB_ROLL_PTR)

已提交读隔离级别:每个语句执行前都会重新生成一个 Read View,快照中只包含已commit的数据 可重复读隔离级别:启动事务时生成一个 Read View,然后整个事务期间都在用这个 Read View,后续的查询语句利用这个 Read View,通过这个 Read View 就可以在 undo log 版本链找到事务开始时的数据,所以事务过程中每次查询的数据都是一样的

什么叫事务启动呢?

  • 执行了 begin/start transaction 命令后,并不代表事务启动了。只有在执行这个命令后,执行了增删查改操作的 SQL 语句,才是事务真正启动的时机
  • 执行了 start transaction with consistent snapshot 命令,就会马上启动事务

快照内容读取原则:

  1. 版本未commit,无法读取生成快照
  2. 版本已commit,但是在快照创建后提交的,无法读取
  3. 版本已commit,但是在快照创建前提交的,可以读取
  4. 当前事务做的修改,是需要重新生成快照的。读取的是最新版本,并且对数据加锁,阻塞其他操作事务修改记录。核心逻辑就是判断版本链中的哪个版本是当前事务可见可处理的

"数据快照"中并不是数据,存储的是一些事务id

image.png

Read View 有四个重要的字段:

  • creator_trx_id :指的是创建该 Read View 的事务的事务 id
  • m_ids :指的是在创建 Read View 时,当前数据库中「活跃事务」的事务 id 列表,注意是一个列表,“活跃事务”指的就是,启动了但还没提交的事务。重新生成数据快照m_ids可能会有更新,不重新生成数据快照m_ids就不会更新
  • min_trx_id :指的是在创建 Read View 时,当前数据库中「活跃事务」中事务 id 最小的事务,也就是 m_ids 的最小值
  • max_trx_id :这个并不是 m_ids 的最大值,而是创建 Read View 时当前数据库中应该给下一个事务的 id 值,也就是所有已提交的和未提交的事务中最大的事务 id 值 + 1

Innodb如何判断某条记录是否对当前事务可见呢?一个事务去访问记录的时候,除了自己的更新记录总是可见之外,还有这几种情况:

  • 如果记录的 trx_id 值小于 Read View 中的 min_trx_id 值,表示这个版本的记录是在创建 Read View 前已经提交的事务生成的,所以该版本的记录对当前事务可见
  • 如果记录的 trx_id 值大于等于 Read View 中的 max_trx_id 值,表示这个版本的记录是在创建 Read View 后才启动的事务生成的,所以该版本的记录对当前事务不可见
  • 如果记录的 trx_id 值在 Read View 的 min_trx_id 和 max_trx_id 之间,需要判断 trx_id 是否在 m_ids 列表中:
  • 如果记录的 trx_id 在 m_ids 列表中,表示生成该版本记录的活跃事务依然活跃着(还没提交事务),所以该版本的记录对当前事务不可见
  • 如果记录的 trx_id 不在 m_ids列表中,表示生成该版本记录的活跃事务已经被提交,所以该版本的记录对当前事务可见

这种通过「版本链」来控制并发事务访问同一个记录时的行为就叫 MVCC(多版本并发控制)

在已提交读隔离级别下,每次查询都会重新生成数据快照,若其他事务已经提交了,当前事务再次查询时重新生成的数据快照中的m_ids、min_trx_id、max_trx_id可能会发生改变,这样对比每条记录的trx_id后,可见性就会发生改变

在可重复读隔离级别下,每次查询都使用第一次生成的数据快照

二、MVCC应用于已提交读隔离级别

1. 解决脏读

先设置隔离级别为已提交读并开启事务,已提交读解决了脏读,未解决可重复读和幻读

image.png

image.png

这样通过快照读,MVCC就解决了脏读

不管是已提交读还是可重复读,只要我们select的时候,就会产生一个数据快照,相当于给当前的数据拍个照片,以后去查询,都是查询快照上的数据(除非有新的数据被commit)。已提交读隔离级别采用非锁定读,非锁定读是在快照上的读取。

在已提交读隔离级别,每一次select都会产生一个新的数据快照,当事务1进行更改的时候,事务2又去select,重新产生数据快照(有可能和前面的快照相同),然而产生新的数据快照的前提是新的数据已经被事务正确commit,prepare状态的数据不会出现在快照中

数据有2种状态:prepare(未提交时)和commit(已提交)

事务2第二次select的时候,由于事务1并没有commit新的数据(数据处于prepare状态),当又一次产生数据快照时,产生的数据快照还是undo log回滚日志的链表指向的旧数据,这就解决了脏读问题

然而,在已提交读隔离级别依然会发生不可重复读的现象(两次查询,得到的数据内容不一样,属于正确读取的范围)


2. 无法解决不可重复读

因为每一次select都会重新产生1次数据快照,其他事务update后commit,新的数据已经符合生成快照的要求了,于是再次select的时候新commit的数据也会出现在新生成的快照中,发生了不可重复读

3. 无法解决幻读

image.png

image.png

和出现不可重复读现象的原因相同,由于新commit的数据符合生成快照的要求,再次select的时候新commit的数据也会出现在新生成的快照中,自然就出现了幻读

三、MVCC应用于可重复读隔离级别

1. 解决脏读

事务第一次select就产生数据快照,而且只产生这一次快照,select时都是直接用老的数据快照,所以可以解决脏读

2. 解决不可重复读

因为事务第一次select就产生数据快照,而且只产生这一次快照

设置可重复读隔离级别,并2个开启事务

image.png

事务2 select,生成数据快照,在可重复读隔离级别下,以后再select都不会再生成快照

image.png

生成的快照如下:

image.png

事务1进行update,然后commit

image.png

我们update以后,表格就变成了这样:

image.png

我们事务2再次select id=12的数据,这时候就是在事务2第一次select生成的快照上查数据了

image.png

这就解决了不可重复读!!!

3. 理解 可重复读隔离级别,只生成一次数据快照

再举一个例子理解:在可重复读隔离级别,只生成一次数据快照

image.png

image.png

由于事务1已经commit了,新的数据不再是prepare状态,已经符合了生成快照的条件。当事务2再select(快照读)的时候,这条age=22的数据自然就被查到了

4. 理解 可重复读隔离级别,只能部分解决幻读

先查看表数据

image.png

回滚并重启事务

image.png

image.png

事务2生成的快照如下:

image.png

事务2第一次select是两条数据,事务1 insert之后,事务2再次select依然是两条,看似解决了幻读,其实只是部分解决(并不能完全解决幻读)

那我们看一下为什么是部分解决幻读

事务1 insert然后commit后,表格的数据应该是这样的

image.png

此时事务2 update

image.png

可以看见,update找到了id=24的数据,这就证明update做的是当前读(读最新的commit状态的数据),而不是快照读,因为快照上根本就没有id=24的数据

image.png

其中1000是事务1的ID,2000的事务2的ID

由于每个事务可以看见自己修改、更新的数据,当事务2再次select的时候,就可以看见id=24的数据了,这就发生了幻读(主要因为insert,delete,update,select…lock in share mode/for update这些操作,是当前读)

image.png

未提交读 已提交读 可重复读 串行化
/ MVCC MVCC + 临键锁 临键锁
脏读、不可重复读、幻读 不可重复读、幻读 幻读 /


相关实践学习
如何快速连接云数据库RDS MySQL
本场景介绍如何通过阿里云数据管理服务DMS快速连接云数据库RDS MySQL,然后进行数据表的CRUD操作。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
9天前
|
存储 SQL 关系型数据库
MySQL进阶突击系列(03) MySQL架构原理solo九魂17环连问 | 给大厂面试官的一封信
本文介绍了MySQL架构原理、存储引擎和索引的相关知识点,涵盖查询和更新SQL的执行过程、MySQL各组件的作用、存储引擎的类型及特性、索引的建立和使用原则,以及二叉树、平衡二叉树和B树的区别。通过这些内容,帮助读者深入了解MySQL的工作机制,提高数据库管理和优化能力。
|
1月前
|
存储 关系型数据库 MySQL
MySQL MVCC全面解读:掌握并发控制的核心机制
【10月更文挑战第15天】 在数据库管理系统中,MySQL的InnoDB存储引擎采用了一种称为MVCC(Multi-Version Concurrency Control,多版本并发控制)的技术来处理事务的并发访问。MVCC不仅提高了数据库的并发性能,还保证了事务的隔离性。本文将深入探讨MySQL中的MVCC机制,为你在面试中遇到的相关问题提供全面的解答。
209 2
|
10天前
|
缓存 关系型数据库 MySQL
MySQL 索引优化与慢查询优化:原理与实践
通过本文的介绍,希望您能够深入理解MySQL索引优化与慢查询优化的原理和实践方法,并在实际项目中灵活运用这些技术,提升数据库的整体性能。
40 5
|
22天前
|
SQL 存储 关系型数据库
MySQL进阶突击系列(01)一条简单SQL搞懂MySQL架构原理 | 含实用命令参数集
本文从MySQL的架构原理出发,详细介绍其SQL查询的全过程,涵盖客户端发起SQL查询、服务端SQL接口、解析器、优化器、存储引擎及日志数据等内容。同时提供了MySQL常用的管理命令参数集,帮助读者深入了解MySQL的技术细节和优化方法。
|
1月前
|
存储 关系型数据库 MySQL
MySQL MVCC深度解析:掌握并发控制的艺术
【10月更文挑战第23天】 在数据库领域,MVCC(Multi-Version Concurrency Control,多版本并发控制)是一种重要的并发控制机制,它允许多个事务并发执行而不产生冲突。MySQL作为广泛使用的数据库系统,其InnoDB存储引擎就采用了MVCC来处理事务。本文将深入探讨MySQL中的MVCC机制,帮助你在面试中自信应对相关问题。
160 3
|
2月前
|
SQL 关系型数据库 MySQL
Mysql中搭建主从复制原理和配置
主从复制在数据库管理中广泛应用,主要优点包括提高性能、实现高可用性、数据备份及灾难恢复。通过读写分离、从服务器接管、实时备份和地理分布等机制,有效增强系统的稳定性和数据安全性。主从复制涉及I/O线程和SQL线程,前者负责日志传输,后者负责日志应用,确保数据同步。配置过程中需开启二进制日志、设置唯一服务器ID,并创建复制用户,通过CHANGE MASTER TO命令配置从服务器连接主服务器,实现数据同步。实验部分展示了如何在两台CentOS 7服务器上配置MySQL 5.7主从复制,包括关闭防火墙、配置静态IP、设置域名解析、配置主从服务器、启动复制及验证同步效果。
Mysql中搭建主从复制原理和配置
|
2天前
|
存储 Oracle 关系型数据库
数据库传奇:MySQL创世之父的两千金My、Maria
《数据库传奇:MySQL创世之父的两千金My、Maria》介绍了MySQL的发展历程及其分支MariaDB。MySQL由Michael Widenius等人于1994年创建,现归Oracle所有,广泛应用于阿里巴巴、腾讯等企业。2009年,Widenius因担心Oracle收购影响MySQL的开源性,创建了MariaDB,提供额外功能和改进。维基百科、Google等已逐步替换为MariaDB,以确保更好的性能和社区支持。掌握MariaDB作为备用方案,对未来发展至关重要。
10 3
|
2天前
|
安全 关系型数据库 MySQL
MySQL崩溃保险箱:探秘Redo/Undo日志确保数据库安全无忧!
《MySQL崩溃保险箱:探秘Redo/Undo日志确保数据库安全无忧!》介绍了MySQL中的三种关键日志:二进制日志(Binary Log)、重做日志(Redo Log)和撤销日志(Undo Log)。这些日志确保了数据库的ACID特性,即原子性、一致性、隔离性和持久性。Redo Log记录数据页的物理修改,保证事务持久性;Undo Log记录事务的逆操作,支持回滚和多版本并发控制(MVCC)。文章还详细对比了InnoDB和MyISAM存储引擎在事务支持、锁定机制、并发性等方面的差异,强调了InnoDB在高并发和事务处理中的优势。通过这些机制,MySQL能够在事务执行、崩溃和恢复过程中保持
14 3
|
2天前
|
SQL 关系型数据库 MySQL
数据库灾难应对:MySQL误删除数据的救赎之道,技巧get起来!之binlog
《数据库灾难应对:MySQL误删除数据的救赎之道,技巧get起来!之binlog》介绍了如何利用MySQL的二进制日志(Binlog)恢复误删除的数据。主要内容包括: 1. **启用二进制日志**:在`my.cnf`中配置`log-bin`并重启MySQL服务。 2. **查看二进制日志文件**:使用`SHOW VARIABLES LIKE 'log_%';`和`SHOW MASTER STATUS;`命令获取当前日志文件及位置。 3. **创建数据备份**:确保在恢复前已有备份,以防意外。 4. **导出二进制日志为SQL语句**:使用`mysqlbinlog`
20 2
|
16天前
|
关系型数据库 MySQL 数据库
Python处理数据库:MySQL与SQLite详解 | python小知识
本文详细介绍了如何使用Python操作MySQL和SQLite数据库,包括安装必要的库、连接数据库、执行增删改查等基本操作,适合初学者快速上手。
104 15

推荐镜像

更多