简述Mysql InnoDB的MVCC机制

本文涉及的产品
云数据库 RDS MySQL,集群版 2核4GB 100GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
RDS MySQL Serverless 高可用系列,价值2615元额度,1个月
简介: 简述Mysql InnoDB的MVCC机制

什么是MVCC

MVCC是Multi-Version Concurrency Control的缩写,也就是多版本并发控制。在Mysql InnoDB中用来处理读写冲突,实现非阻塞并发读,以达到更好的数据库并发性能。

当前读和快照读

说到MVCC,就不得不提当前读和快照读。

  • 当前读
    当前读,顾名思义就是读取当前的最新数据。比如select for updateselect lock in share modeupdateinsertdelete等都属于当前读,因为这些操作都会对数据进行加锁,避免其他并发事务不能修改当前记录,以保证读取到的是最新数据。
  • 快照读
    快照读就是读取某一时刻的记录,读取这样的数据是不需要加锁的。比如select操作就是快照读,这样处理可以有效提升数据库的并发读写能力。快照读的实现就是基于MVCC。

也就是说,当前读和快照读的区别就在于:当前读是加锁的,是悲观锁的实现;快照读是不加锁的,基于MVCC实现;

MVCC解决了什么问题

  • 数据库读写并发能力
    在并发读写数据时,可以做到在读写操作不用相互阻塞,提升数据库并发读写性能;因为select操作是快照读,updateinsertdelete操作是当前读,两者不会相互阻塞;
  • 解决脏读、不可重复读、幻读等问题
    MVCC与Read View结合可以解决脏读、不可重复读、幻读事务隔离问题;

MVCC是怎么实现的

MVCC设计出来的目的就是为了解决读写冲突,它的实现主要依赖于4个隐式字段、undolog、Read View;

  • 隐式字段
    数据库在每一行数据记录外额外增加了3个隐式字段:
DB_ROW_ID DB_TRX_ID DB_ROLL_PTR DELETED_BIT
隐藏主键 事务ID 回滚指针 记录被更新或者被删除标记

1.隐藏主键:隐含的自增ID,如果数据表没有设置主键,InnoDB会自动以DB_ROW_ID生成一个聚簇索引;

2.事务ID:记录创建这条记录/或者最后一次修改这条记录的事务ID;

3.回滚指针:记录这条记录的上一个版本;

4.记录被更新或者被删除标记:修改操作是给当前记录打上DELETED_BIT=true的标记,另外再创建一条新记录;删除操作是给当前记录打上DELETED_BIT=true的标记;都不是真正地把数据删掉;

  • undo日志

除了查询操作不会记录undo log外,其他的updateinsertdelete操作都会记录对应的undo log;

1.比如有一个user表已经插入一条新记录,name=zouwei,age=28,隐藏主键为1:

image.png

2.现在再来一个事务1针对该记录的name做出修改,改名为Z

  • 在事务1修改该记录时,数据库先给该记录加上排他锁;
  • 然后再把当前记录拷贝一份到undo log中,DELETED_BIT设置为true;
  • 拷贝完毕后,修改改记录name=Z,并把DB_TRX_ID设置为1,DB_ROLL_PTR指向undlog中的副本,也就是当前记录的上一个版本;
  • 事务提交,释放排他锁;

image.png

  • 3.再来一个事务2修改该记录的age=30
  • 在事务2修改该记录时,同样先给该记录加上排他锁;
  • 然后再把当前记录拷贝一份到undo log中,DELETED_BIT设置为true;
  • 拷贝完毕后,修改改记录age=30,并把DB_TRX_ID设置为2,DB_ROLL_PTR指向undlog中的副本,也就是当前记录的上一个版本;
  • 事务提交,释放排他锁;

image.png

  • 也就是说,不同事务针对同一记录做修改,undo log会产生该记录的版本链条,链首是该记录的最新旧数据,链尾是该记录的最早旧数据;
  • Read ViewRead View就是在事务中,执行快照读操作时,生成的读视图;在该事务执行快照读的那一刻,会生成数据库当前的一个快照,记录并维护了当前活跃的事务ID(事务ID被分配时是递增的);Read View的作用就是用来判断在执行快照读时,当前事务在undo log链中,哪些旧数据是可以被看见的;Read View可见性算法大致如下:

Read View中包含大概三个全局属性:

1.trx_list:未提交事务ID列表;

2.up_limit_id:trx_list中的最小事务ID;

3.low_limit_id:创建视图那一刻,下一个系统尚未分配的事务ID;

  • 在undo log中,DB_TRX_ID小于up_limit_id的记录都是可见的;
  • 如果DB_TRX_ID大于low_limit_id,那么说明该记录时在创建Read View后写进来的,那肯定是不可见的;
  • 那么还要检测DB_TRX_ID是否在trx_list中,如果不在,那么说明事务已经提交,那么该记录可见,否则说明该事务还未提交,不可见;

Read View在RR隔离级别和RC隔离级别的区别

  • 在RR隔离级别下,事务对某条记录的第一次快照读会创建一个Read View,此后再调用快照读的时候,使用的还是同一个Read View;所以当前事务只要在其他事务提交之前使用过快照读,那么即使其他事务已经提交了,因为使用的是同一个Read View,所以依然还是看不见提交的数据;
  • 在RC隔离级别下,每一次快照读都会重新生成一个新的Read View,所以我们就可以在RC隔离级别下看到其他事务提交的数据;


相关实践学习
如何在云端创建MySQL数据库
开始实验后,系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
27天前
|
存储 关系型数据库 MySQL
MySQL数据库进阶第六篇(InnoDB引擎架构,事务原理,MVCC)
MySQL数据库进阶第六篇(InnoDB引擎架构,事务原理,MVCC)
|
19天前
|
关系型数据库 MySQL
mysql事务隔离级别MVCC
mysql事务隔离级别MVCC
|
21天前
|
存储 关系型数据库 MySQL
深入浅出MySQL事务管理与锁机制
MySQL事务确保数据一致性,ACID特性包括原子性、一致性、隔离性和持久性。InnoDB引擎支持行锁、间隙锁和临键锁,提供四种隔离级别。通过示例展示了如何开启事务、设置隔离级别以及避免死锁。理解这些机制对优化并发性能和避免数据异常至关重要。【6月更文挑战第22天】
98 3
|
21天前
|
存储 关系型数据库 MySQL
关系型数据库mysql的InnoDB
【6月更文挑战第17天】
20 3
|
18天前
|
存储 关系型数据库 MySQL
重温MySQL的ACID实现原理:深入探索底层设计与机制
重温MySQL的ACID实现原理:深入探索底层设计与机制
|
19天前
|
关系型数据库 MySQL 调度
深入理解MySQL InnoDB线程模型
深入理解MySQL InnoDB线程模型
|
19天前
|
存储 关系型数据库 MySQL
mysql的InnoDB引擎实现ACID特性的原理
mysql的InnoDB引擎实现ACID特性的原理
|
9天前
|
存储 关系型数据库 MySQL
探索MySQL:关系型数据库的基石
MySQL,作为全球最流行的开源关系型数据库管理系统(RDBMS)之一,广泛应用于各种Web应用、企业级应用和数据仓库中
|
7天前
|
关系型数据库 MySQL 网络安全
Mysql 数据库主从复制
在MySQL主从复制环境中,配置了两台虚拟机:主VM拥有IP1,从VM有IP2。主VM的`my.cnf`设置server-id为1,启用二进制日志;从VM设置server-id为2,开启GTID模式。通过`find`命令查找配置文件,编辑`my.cnf`,在主服务器上创建复制用户,记录二进制日志信息,然后锁定表并备份数据。备份文件通过SCP传输到从服务器,恢复数据并配置复制源,启动复制。检查复制状态确认运行正常。最后解锁表,完成主从同步,新用户在从库中自动更新。
919 6
Mysql 数据库主从复制
|
7天前
|
缓存 运维 关系型数据库
数据库容灾 | MySQL MGR与阿里云PolarDB-X Paxos的深度对比
经过深入的技术剖析与性能对比,PolarDB-X DN凭借其自研的X-Paxos协议和一系列优化设计,在性能、正确性、可用性及资源开销等方面展现出对MySQL MGR的多项优势,但MGR在MySQL生态体系内也占据重要地位,但需要考虑备库宕机抖动、跨机房容灾性能波动、稳定性等各种情况,因此如果想用好MGR,必须配备专业的技术和运维团队的支持。 在面对大规模、高并发、高可用性需求时,PolarDB-X存储引擎以其独特的技术优势和优异的性能表现,相比于MGR在开箱即用的场景下,PolarDB-X基于DN的集中式(标准版)在功能和性能都做到了很好的平衡,成为了极具竞争力的数据库解决方案。