Innodb-MVCC详解

Innodb-MVCC详解

借用高性能 MySQL 的几句话

MySQL 的大多数事务型存储引擎都不是简单的行级锁,基于提升并发性能考虑,他们一般都同时实现了多版本并发控制 MVCC,但各自的实现机制不尽相同,因为 MVCC 没有一个统一的实现标准。

可以认为 MVCC 是行级锁的一个变种,但是他在很多情况下避免了枷锁操作,因此开销更低,虽然实现机制有所不同,但大都实现了非阻塞的读操作,写操作也只锁定必要的行。

我们先来分析为什么个大多数据库都实现了 MVCC 以及实现的好处

  • 项目日常运行中绝大部分的是查询语句,如果实现的方式是读锁(共享锁)的方式那么,在大量读的情况下需要去阻塞写操作,如果涉及到了部分写操作,大量的锁争用问题,可能会导致读写操作无法获得锁去执行。

  • 如果读不用加锁,那么对于系统的吞吐量一定是海量的提升。

  • 写操作 (insert/update/delete),lock 等操作施加最小级别的锁,依次为主键行锁、唯一索引+主键行锁、间隙锁、范围锁、全表主键锁。当在其吞吐量较高的情况下,施加不同的锁对于系统的性能影响都比较大,需要考验开发者的一个技术水平。

再来借用高性能 MySQL 的几句话

  • MVCC 的实现是通过某个时间点的快照来实现的

  • 是通过在每行记录后面保存系统版本号来实现的,每开启一个事务,系统版本号递增并且将值赋值给事务版本号,然后查询的时候只会去查找行的版本号早于当前事务版本号的行...

在这个地方,因为 它没有仔细的介绍,相信有的读者可能会有一些问题,如下:

  • 某个时间的快照是什么,是一个完整的复制的镜像文件,还是 mvcc 实现,还是数据库数据备份等等?

  • 既然有了当前事务的快照了,那么读取的数据肯定是当前时间点事务的快照数据,为什么还需要 根据什么系统版本号,事务版本号,行版本号去 curd 数据呢?

通过下来分析你就会明白了

Innodb,MVCC 的读可以分为2种,快照读当前读,这里只介绍 RR 隔离界别

在这之前我们先来了解几个概念便于我们理解

首先
Innodb 会为每一行数据添加3个字段分别是

  • DATA_TRX_ID
    表示当前事务递增得到的事务id作为其行版本号

  • DATA_ROLL_PTR
    一个指向 undo 信息的指针,undo 就是实现 mvcc 的关键,等等会介绍。

  • DELETED_BIT
    标识该记录是否被删除

其次

我们要注意的一个地方就是,快照的创建默认是在你执行第一条 SQL 语句的时候,事务的真正开启也在这个时候,我们这里的讲解默认开启事务就创建快照即执行了 start transaction with consistent snapshot;

undo
在 mvcc 中,当用户读取一条记录的时候,若此记录已经被其它事务占用,当前事务就可以通过undo log 读取之前的行的版本信息,找到行版本号小于等于当前事务版本号的数据。以及读取到一条被标识为删除的数据的时候,也可以通过undo log 来获取之前版本正常的数据。这里不理解的话没有关系,看完下面的内容再来看这句话就明白了。

快照读

快照数据就是当前行数据之前的历史版本,每行记录都可能有多个版本,每一行记录也可能同时存在多个快照数据。所以称之为 多版本并发控制 MVCC,每个事务开启的时候都会创建一个 read view,它定义在 readOread.h 文件中,用来检索行的可见性

dulint   low_limit_id; // 当前开启事务的 id,每开启一个事务系统版本号递增并且赋值给事务系统版本号
dulint   up_limit_id; // 当前活跃事务最小的事务 id
ulint    n_trx_ids; // 当前活跃事务 id 的数量
dulint*  trx_ids; // 当前活跃事务的 id 列表

每开启一个事务的时候和已经存在的事务的记录的一个记录

我们假设现目前用户 A 开启了一个事务 id 为 10,目前存在事务 9、8、7、6 即

low_limit_id = 10;
up_limit_id = 6
n_trx_ids = 5
trx_ids = [6,7,8,9,10]

用户 B 开启事务的时候 id 为 9, 存在事务 8、7、6

low_limit_id = 9;
up_limit_id = 6
n_trx_ids = 4
trx_ids = [6,7,8,9]

然后我们先分析 select 的几种情况

  • select
    比如当前处于用户 B
    只会检索行的系统版本号小于等于当前事务的版本号保证数据是在事务开启之前就已经提交了了的或者是自己插入的。
    也就是必须 < 6 (up_limit _id) 的行的版本号才是可见的
    同理对于用户 A 来说必须是 < 6 的行的系统版本号才是可见的

  • insert/update/delete 属于当前读,下面介绍

当前读

  • select ... lock in share mode

  • select ... for update

  • insert

  • update

  • delete

当前读不同于快读的地方是,当前读读取的是系统最新的数据,它首先回去获取锁,获取到锁后执行对应的上述操作,事务完成后再释放锁不是修改完成后。如果这个时间段存在其它的事务当前读那么久会阻塞其它事务。那么如果这个地方的更新不是主键或者唯一索引级别的话会涉及到幻读,它是采用了间隙锁(next-key locking)策略防止幻读的出现。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 194,319评论 5 459
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 81,801评论 2 371
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 141,567评论 0 319
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 52,156评论 1 263
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 61,019评论 4 355
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 46,090评论 1 272
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 36,500评论 3 381
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 35,192评论 0 253
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 39,474评论 1 290
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 34,566评论 2 309
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 36,338评论 1 326
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 32,212评论 3 312
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 37,572评论 3 298
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 28,890评论 0 17
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,169评论 1 250
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 41,478评论 2 341
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 40,661评论 2 335

推荐阅读更多精彩内容