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)策略防止幻读的出现。

你可能感兴趣的:(Innodb-MVCC详解)