”真正学会,如你般自由~“
MVCC机制简介
MVCC(Multi-Version-Concurrency-Control)多版本并发控制,MVCC 是一种并发控制的方法,一般在数据库管理系统中,实现对数据库的并发访问;在编程中实现事务内存。
MVCC存在被使用于多个大型数据库软件,诸如Mysql、Oracle、PostgreSQL等。其中,在Mysql存储引擎中,MVCC机制的运用,对于Innodb支持事务,更好的处理读-写并发,提高并发性能等具有支撑作用。
MVCC带来的好处?
数据并发的三种场景:
🥊 写-写: 有线程安全问题,只能串行化执行。
🥊 读-写: 有线程安全问题,可能会造成事务隔离性问题,可能遇到脏读,幻读,不可重复读。
🥊 读-读: 不存在任何问题,也不需要并发控制。
MVCC主要为 读-写情况提供无锁并发控制:
- 在并发读写数据库时,可以做到在读操作时不用阻塞写操作,写操作也不用阻塞读操作,提高了数据库并发读写的性能
- 同时还可以解决脏读,幻读,不可重复读等事务隔离问题,但不能解决更新丢失问题
概念辨析
💎 如何理解事务?
说起事务的概念,其本质并不复杂。我们可以将其理解为 一组“操作逻辑”,而这套逻辑天然需要支持四大特性: 原子性、持久性、隔离性、一致性 —— ACID。
在Mysql中,分别采用不同的措施来保证 事务这四大特性:
🎫 通过回滚机制,保证sql在执行的过程中要么都被执行成功,要么都执行失败 —— 原子性
🎫 事务一旦提交,数据就是永久的 —— 持久性
🎫 通过隔离级别,保证各个开启事务、执行SQL不会互相干扰 —— 隔离性
Mysql唯独没有对保证 一致性做任何操作,但为保障其他三个特点所做的技术,最终就是为了保证事务的一致性!
💎 当前读 vs 快照读
当前读: 就是它读取的是记录的最新版本
快照读: 读取为历史版本
我们可以先看一个实验,我们先将Mysql中的隔离界别调整为RC(Mysql默认的隔离级别为RR)
重启客户端后,就可以查看到修改字段:
创建一个新表,并在其中插入一些数据:
RC隔离级别下的事务:
这很符合预期,毕竟咱们设置的隔离级别就是 “RC”,即读可提交。
RR默认隔离级别下的事务:
我们现在按照统一的操作,在RR隔离级别下会发生什么呢?
是的,我们再也无法看到另一端启动的事务 对表做的任何修改,即便它执行了“commit”!
直观地,在RR下两个事务进行select的表一定是不同的!而这两个不同的表,一张记录的是当前数据信息,而另一张表记录的则是历史数据!
当我们使用,像"select lock in share mode"在锁机制下的查询sql,就能读取到对端事务提交修改的新数据。
由此,所谓当前读 与 快照读的本质,就是查询的表信息版本的不同~通过控制、管理 不同的版本信息,从而实现隔离性~ 对于,事务能看到的版本范围,则是由 “隔离级别“ 决定!隔离级别是怎样实现,Mysql是如何管理这个过程的,则是依赖MVCC机制从根本上提供技术支持。
MVCC机制实现原理
MVCC目的在于 —— 多版本并发控制。为了解决读-写场景下产生的问题,MVCC通过3个核心机制完成控制和管理:
🔮 3个记录的隐藏字段
🔮 undo日志
🔮 Read View
3个隐式字段
⛳ DB_TRX_ID:
6 byte,最近修改( 修改/插入 )事务ID,记录创建这条记录/最后一次修改该记录的事务ID。
⛳ DB_ROLL_PTR
回滚指针,指向这条记录的上一个版本,通过这个指针,从而形成一个历史版本链。
⛳ DB_ROW_ID
undo日志
undo log有两个作用:提供回滚和多个行版本控制,它是一个逻辑日志。
当sql语句是insert\delete时,记录这条操作的同时,也会在该日志中对应插入delete\insert 语句,用于回滚。同样,如果是遇到 update命令时,也会将原数据进行一份拷贝,再进行修改,并让新表中的 回滚指针,填写原版本的地址(这里的地址,指的时undo天然可以看成一块内存缓冲区,当数据被写入内存时,天然就会携带内存地址)。
上面的一个一个版本,我们可以称之为一个一个的快照。当我们开启快照读,就是到这里面存储的表中读取数据!至于哪些版本是我们应该看到的,就与我们下一小节的read view决定了!
read View
所谓read view,就是事务进行 "快照读"操作时,产生出的读视图。任何一个事务启动时,都会被分配一个事务ID!而这个事务ID是线性递增的~言外之意,事务ID越小,说明该事务到来得越早!
read view是事务进行快照读所产生的,它需不需要记录是哪个事务执行的这个操作?它需不需要保存快照读时刻下,哪些事务是“活跃的”(即未进行commit,仍处于事务状态的ID)?……
一个Mysql服务中,一定不止一个事务启动,一定不止一次快照读产生的不止一个read view,这些东西需不需要管理? 答案是都需要!如何管理呢? 先描述,再组织~ 因此,read view其本质上就是一个结构体(类对象)!
下面是 我们简化一下的ReadView 结构:
class ReadView {
// 省略...
private:
/** 高水位,大于等于这个ID的事务均不可见*/
trx_id_t m_low_limit_id
/** 低水位:小于这个ID的事务均可见 */
trx_id_t m_up_limit_id;
/** 创建该 Read View 的事务ID*/
trx_id_t m_creator_trx_id;
/** 创建视图时的活跃事务id列表*/
ids_t m_ids;
/** 配合purge,标识该视图不需要小于m_low_limit_no的UNDO LOG,
* 如果其他视图也不需要,则可以删除小于m_low_limit_no的UNDO LOG*/
trx_id_t m_low_limit_no;
/** 标记视图是否被关闭*/
bool m_closed;
};
🥎 m_ids: 用来维护Read View生成时刻,系统正活跃的事务ID
🥎 creator_trx_id: 创建该ReadView的事务ID
🥎 up_limit_id: m_ids中,最小的事务ID
🥎 low_limit_id: ReadView生成时刻系统尚未分配的下一个事务ID
当我们获取历史版本链时,每一个事务所能看到的版本都应该是受限制的,比如一个早来到的事务,不可能了解到后到事务对表数据进行的修改,正如 古人先贤不会对当今的智能时代加以评论、享受。
我们read view手头中,正有DB_TRX_ID能够标识事务的先后顺序……
这个可见性过程是怎样的?我们可以参照如下流程:
🏀 此时到来一个 creator_ID事务ID,它现在进行了一次快照读,生产read view,记录下了当前活跃的事务ID,更新了up_limit_id \ low_limit_id。它会去undo日志中,寻找任意一条记录,并获取上面的 DB_TRX_ID。
🏀 DB_TRX_ID < up_limit_id。如果小于,则事务能够看到这条记录。反之,我们继续往下走~
🏀 DB_TRX_ID >= low_limit_id。如果大于,则该事务不能看到这条记录,反之我们继续往下走~
🏀 DB_TRX_ID IN [m_ids]。如果该事务ID不存在活跃事务之中,那么就能看到这条记录,反之就不能。
RR与RC机制的本质区别
总结这两种隔离级别的区别就是一句话,” 形成快照的时机不同 “。
RC: 每一次查询都会创建read view,保证读取当前最新版本。
RR: 只能生产一次read view,之后的一切查询读取都只能按照这个read view读取。
正是RC每次快照读,都会形成Read View,所以,RC才会有不可重复读问题。
本篇到此结束,感谢你的阅读。
祝你好运,向阳而生~