MVCC(多版本并发控制)

一、什么是MVCC

MVCC是为了解决数据库在不加锁的前提下提升并发性和读取效率的一种思想

数据库有已下几种并发情况

  • 读-读:不会产生并发问题
  • 读-写:发生隔离性问题,可能导致脏读、幻读、不可重复度
  • 写-写:可能存在数据丢失

为了防止并发问题,一般采用两种读取方式;

  • 当前读:DML语句和加排它锁,select lock in share mode加共享锁,确保读取为最新数据
  • 快照读:读写时不加锁、可能读取到历史数据

当前读(加锁)+快照(MVCC)读保证了事务的隔离性

MVCC 就是为了实现读-写冲突不加锁,而这个读指的就是快照读, 而非当前读,当前读实际上是一种加锁的操作,是悲观锁的实现


二、MVCC实现原理

三个部分:隐式字段+undo版本链+read view视图

2.1、隐式字段

表内的每行记录除了我们自定义的字段外,还有数据库隐式字段段DB_TRX_ID, DB_ROLL_PTR, DB_ROW_ID

  • DB_TRX_ID :记录创建这条记录或最后一次修改该记录的事务 ID
  • DB_ROLL_PTR:回滚指针,指向这条记录的上一个版本
  • DB_ROW_ID:隐含的自增 ID(隐藏主键),当前表没有主键,InnoDB 自动产生聚集索引

2.2、undo版本链

不同的事务或相同事务对同一条记录修改是,会将当前记录先copy一份当undo log中,同时该记录的DB_TRX_ID会自增,DB_ROLL_PTR指向修改前记录的地址。以此形成版本链表


2.3、read view视图

如上图,现在我们生成了4个版本,当select的时候会选取哪个版本呢?这时候就需要根据read view里维护的字段通过一定规则对比后最终确认所读取的版本

当然,不同隔离级别下生成read view的时机不同

RC级别下:每次select都会生成一个read view

RR级别下:开启事务后第一个select生成read view,后续的select复用当前read view(由此可知在read view相同的情况下,根据一定规则匹配后读取到的版本肯定是相同的,也就解决了不可重复读的问题)

  • m_ids:未提交事务的DTX_ID的集合
  • creator_trx_id:创建read view视图视图的事务ID

总结一下:

当前事务或其它事务修改同一个数据时,会被undolog记录,并通过roll_point形成版本链,接着read view会根据里面维护的字段通过一定规则对比各个版本数据的隐式字段,最终匹配出可查询的版本具体为哪一个。当然,由于隔离级别不同,产生read view的时机不同,读取到的版本也不同,RC:每一次快照度都会产生read view、RR:第一次快照度后产生read view,后续复用

相关推荐
RestCloud1 天前
SQL Server到Hive:批处理ETL性能提升30%的实战经验
数据库·api
RestCloud1 天前
为什么说零代码 ETL 是未来趋势?
数据库·api
ClouGence1 天前
CloudCanal + Paimon + SelectDB 从 0 到 1 构建实时湖仓
数据库
DemonAvenger2 天前
NoSQL与MySQL混合架构设计:从入门到实战的最佳实践
数据库·mysql·性能优化
AAA修煤气灶刘哥2 天前
后端人速藏!数据库PD建模避坑指南
数据库·后端·mysql
RestCloud2 天前
揭秘 CDC 技术:让数据库同步快人一步
数据库·api
得物技术2 天前
MySQL单表为何别超2000万行?揭秘B+树与16KB页的生死博弈|得物技术
数据库·后端·mysql
可涵不会debug3 天前
【IoTDB】时序数据库选型指南:工业大数据场景下的技术突围
数据库·时序数据库
ByteBlossom3 天前
MySQL 面试场景题之如何处理 BLOB 和CLOB 数据类型?
数据库·mysql·面试
麦兜*3 天前
MongoDB Atlas 云数据库实战:从零搭建全球多节点集群
java·数据库·spring boot·mongodb·spring·spring cloud