专栏首页luozhiyun的源码解析一篇文章带你掌握mysql的一致性视图(MVCC)

一篇文章带你掌握mysql的一致性视图(MVCC)

提到事务,你肯定会想到ACID(Atomicity、Consistency、Isolation、Durability,即原子性、一致性、隔离性、持久性),我们就来说说其中I,也就是“隔离性”。

当数据库上有多个事务同时执行的时候,就可能出现脏读(dirty read)、不可重复读(non-repeatable read)、幻读(phantom read)的问题,所以下面我们来说说隔离级别。

SQL标准的事务隔离级别包括:读未提交(read uncommitted)、读提交(read committed)、可重复读(repeatable read)、串行化(serializable)。

  • 读未提交是指,一个事务还没提交时,它做的变更就能被别的事务看到。
  • 读提交指,一个事务提交之后,它做的变更才会被其他事务看到。
  • 可重复读指,一个事务执行过程中看到的数据,总是跟这个事务在启动时看到的数据时一致的。当然可重复读隔离级别下,未提交变更对其他事务也是不可见的。
  • 串行化,顾名思义是对于同一行记录,“写”会加“写锁”,“读”会加“读锁”。当出现读写锁冲突的时候,后访问的事务必须等前一个事务执行完成,才能继续执行。

MySQL中支持的四种隔离级别

MySQL虽然支持4种隔离级别,但与SQL标准中所规定的各级隔离级别允许发生的问题却有些出入,MySQL在REPEATABLE READ隔离级别下,是可以禁止幻读问题的发生的。

我们可以通过: SET [GLOBAL|SESSION] TRANSACTION ISOLATION LEVEL level; 来设置隔离级别。

其中的level可选值有4个:

level: {
     REPEATABLE READ
   | READ COMMITTED
   | READ UNCOMMITTED
   | SERIALIZABLE
}

MVCC原理

对于使用InnoDB存储引擎的表来说,它的聚簇索引记录中都包含必要的隐藏列:

  • trx_id:每次一个事务对某条聚簇索引记录进行改动时,都会把该事务的事务id赋值给trx_id隐藏列。

ReadView

ReadView所解决的问题是使用READ COMMITTED和REPEATABLE READ隔离级别的事务中,不能读到未提交的记录,这需要判断一下版本链中的哪个版本是当前事务可见的。

ReadView中主要包含4个比较重要的内容:

  • m_ids:表示在生成ReadView时当前系统中活跃的读写事务的事务id列表。
  • min_trx_id:表示在生成ReadView时当前系统中活跃的读写事务中最小的事务id,也就是m_ids中的最小值。
  • max_trx_id:表示生成ReadView时系统中应该分配给下一个事务的id值。
  • creator_trx_id:表示生成该ReadView的事务的事务id。

ReadView是如何工作的?

有了这些信息,这样在访问某条记录时,只需要按照下边的步骤判断记录的某个版本是否可见:

  • 如果被访问版本的trx_id属性值与ReadView中的creator_trx_id值相同,意味着当前事务在访问它自己修改过的记录,所以该版本可以被当前事务访问。
  • 如果被访问版本的trx_id属性值小于ReadView中的min_trx_id值,表明生成该版本的事务在当前事务生成ReadView前已经提交,所以该版本可以被当前事务访问。
  • 如果被访问版本的trx_id属性值大于ReadView中的max_trx_id值,表明生成该版本的事务在当前事务生成ReadView后才开启,所以该版本不可以被当前事务访问。
  • 如果被访问版本的trx_id属性值在ReadView的min_trx_id和max_trx_id之间,那就需要判断一下trx_id属性值是不是在m_ids列表中,如果在,说明创建ReadView时生成该版本的事务还是活跃的,该版本不可以被访问;如果不在,说明创建ReadView时生成该版本的事务已经被提交,该版本可以被访问。

如果某个版本的数据对当前事务不可见的话,那就顺着版本链找到下一个版本的数据,继续按照上边的步骤判断可见性,依此类推,直到版本链中的最后一个版本。如果最后一个版本也不可见的话,那么就意味着该条记录对该事务完全不可见,查询结果就不包含该记录。

在MySQL中,READ COMMITTED和REPEATABLE READ隔离级别的的一个非常大的区别就是它们生成ReadView的时机不同。

我们这里使用一个示例来解释:

mysql> CREATE TABLE `t` (
  `id` int(11) NOT NULL,
  `k` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB;
insert into t(id, k) values(1,1) ;

事务A

事务B

begin

begin

update t set k= k+1 where id=1;

commit;

update t set k = k+1 where id=1;

select k from t where id =1;

commit;

在这个例子中,我们做如下假设:

  1. 事务A、B的版本号分别是100、200,且当前系统里只有这3个事务;
  2. 三个事务开始前,(1,1)这一行数据的row trx_id是90。

READ COMMITTED —— 每次读取数据前都生成一个ReadView

继续上面的例子,假设现在有一个使用READ COMMITTED隔离级别的事务开始执行:

# 使用READ COMMITTED隔离级别的事务
BEGIN;

# SELECT1:Transaction 100、200未提交
select k from t where id=1 ; # 得到值为1

这个SELECT1的执行过程如下:

  • 在执行SELECT语句时会先生成一个ReadView,ReadView的m_ids列表的内容就是[100, 200],min_trx_id为100,max_trx_id为201,creator_trx_id为0。
  • 然后从版本链中挑选可见的记录,最新的版本trx_id值为200,在m_ids列表内,所以不符合可见性要求
  • 下一个版本的trx_id值也为100,也在m_ids列表内,所以也不符合要求,继续跳到下一个版本。
  • 下一个版本的trx_id值为90,小于ReadView中的min_trx_id值100,所以这个版本是符合要求的。

之后,我们把事务B的事务提交一下,然后再到刚才使用READ COMMITTED隔离级别的事务中继续查找,如下:

# 使用READ COMMITTED隔离级别的事务
BEGIN;

# SELECT1:Transaction 100、200均未提交
SELECT * FROM hero WHERE number = 1; # 得到值为1

# SELECT2:Transaction 200提交,Transaction 100未提交
SELECT * FROM hero WHERE number = 1; # 得到值为2

这个SELECT2的执行过程如下:

  • 在执行SELECT语句时会又会单独生成一个ReadView,该ReadView的m_ids列表的内容就是[100](事务id为200的那个事务已经提交了,所以再次生成快照时就没有它了),min_trx_id为100,max_trx_id为201,creator_trx_id为0。
  • 然后从版本链中挑选可见的记录,从图中可以看出,最新版本trx_id值为100,在m_ids列表内,所以不符合可见性要求
  • 下一个版本的trx_id值为200,小于max_trx_id,并且不在m_ids列表中,所以可见,返回的值为2

REPEATABLE READ —— 在第一次读取数据时生成一个ReadView 假设现在有一个使用REPEATABLE READ隔离级别的事务开始执行:

# 使用REPEATABLE READ隔离级别的事务
BEGIN;

# SELECT1:Transaction 100、200未提交
SELECT * FROM hero WHERE number = 1; # 得到值为1

这个SELECT1的执行过程如下:

  • 在执行SELECT语句时会先生成一个ReadView,ReadView的m_ids列表的内容就是[100, 200],min_trx_id为100,max_trx_id为201,creator_trx_id为0。
  • 然后从版本链中挑选可见的记录,该版本的trx_id值为100,在m_ids列表内,所以不符合可见性要求
  • 下一个版本该版本的trx_id值为200,也在m_ids列表内,所以也不符合要求,继续跳到下一个版本。
  • 下一个版本的trx_id值为90,小于ReadView中的min_trx_id值100,所以这个版本是符合要求的。

之后,我们把事务B的事务提交一下 然后再到刚才使用REPEATABLE READ隔离级别的事务中继续查找:

# 使用REPEATABLE READ隔离级别的事务
BEGIN;

# SELECT1:Transaction 100、200均未提交
SELECT * FROM hero WHERE number = 1; # 得到值为1

# SELECT2:Transaction 200提交,Transaction 100未提交
SELECT * FROM hero WHERE number = 1; # 得到值为1

这个SELECT2的执行过程如下:

  • 因为当前事务的隔离级别为REPEATABLE READ,而之前在执行SELECT1时已经生成过ReadView了,所以此时直接复用之前的ReadView,之前的ReadView的m_ids列表的内容就是[100, 200],min_trx_id为100,max_trx_id为201,creator_trx_id为0。
  • 然后从版本链中挑选可见的记录,该版本的trx_id值为100,在m_ids列表内,所以不符合可见性要求
  • 下一个版本该版本的trx_id值为200,也在m_ids列表内,所以也不符合要求,继续跳到下一个版本。
  • 下一个版本的trx_id值为90,小于ReadView中的min_trx_id值100,所以这个版本是符合要求的。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 2. Sentinel源码分析—Sentinel是如何进行流量统计的?

    这个方法初始化的时候会调用InitExecutor.doInit() InitExecutor#doInit

    luozhiyun
  • 4. SOFAJRaft源码分析— RheaKV初始化做了什么?

    由于RheaKV要讲起来篇幅比较长,所以这里分成几个章节来讲,这一章讲一讲RheaKV初始化做了什么?

    luozhiyun
  • Dubbo里面线程池的拒绝策略

    luozhiyun
  • MySQL之MVCC初探(1)

    昨天的文章中,我们说了MVCC的基本概念,然后讲了记录额外的两个字段,今天我们通过例子来说明一下MVCC在实际应用中的表现。我们首先创建一张表,然后插入一条...

    AsiaYe
  • MySQL找出未提交事务的信息

    我们经常会碰到这样的情况,某个事务执行完了未提交,后续再来一个DDL和DML操作,导致后面的session要么处于waiting for met...

    用户1148526
  • MySQL-长事务详解

    『入门MySQL』系列文章已经完结,今后我的文章还是会以MySQL为主,主要记录下近期工作及学习遇到的场景或者自己的感悟想法,可能后续的文章不是那么连贯,但还是...

    MySQL技术
  • 【Rust日报】 2019-10-10 Async 进入完善阶段

    来自 Rust 官方 Blog 的博文更新:你可能已经听说过,最近 async-await 功能登陆了 Rust beta 分支。这是 Rust Async 可...

    MikeLoveRust
  • 观点 | 专访Geoff Hinton:全新的想法将比微小的改进更有影响力

    AI 科技评论按,日前,WIRED 对 Hinton 进行了一次专访,在访谈中,WIRED 针对人工智能带来的道德挑战和面临的挑战等问题进行了提问,以下为谈话内...

    AI科技评论
  • 分表查询统计的一个具体案例

    问题描述 mysql数据库在数据量较大的情况下,对数据表进行水平分表,按照年份,如下:

    后端技术探索
  • js list数据 转 树状 层级 JSON,递归生成树状 层级 JSON

    <!DOCTYPE html> <html> <head> <script> var data=[ {"id":"aaa","parentId":"accoun...

    庞小明

扫码关注云+社区

领取腾讯云代金券