InnoDB存储引擎MVCC实现原理

内容简介：InnoDB存储引擎MVCC实现原理

MySQL是现在最流行的关系型数据库(RDB)的选择, 创建一个应用时，无论是用户数据还是订单数据，使用关系型数据库存储是最可靠稳定的选择，借助RDB提供的可靠性、事务等功能，为应用提供完善的支持。MySQL是开源软件，可以免费使用，MySQL在发展多年后越来越成熟，成为大部分公司的数据库首选。MySQL采用插件式的存储引擎架构，5.5版本后默认使用InnoDB存储引擎。

MySQL架构

MVCC

MVCC是Multi Version Concurrency Control的简称，代表多版本并发控制。为什么需要MVCC，还要从数据库事务的ACID特性说起。

相信很多朋友都了解ACID，它们分别代表了Atomicity(原子性), Consistency(一致性), Isolation(隔离性), Durability(持久性)。

原子性表示一个事务的操作结果要么全部执行要么全部不执行。

一致性表示事务总是从一个一致的状态转换到另一个一致的状态。

隔离性表示一个事务的修改结果在什么时间能够被其他事务看到，SQL1992规范中对隔离性定义了不同的隔离级别，

分为读未提交(READ UNCOMMITED),事务能够看到其他事务没有提及的修改，当另一个事务又回滚了修改后的情况又被称为脏读dirty read。

读已提交(READ COMMITTED),事务能够看到其他事务提交后的修改，这时会出现一个事务内两次读取数据可能因为其他事务提交的修改导致不一致的情况，称为不可重复读。 可重复读(REPEATABLE READ)，在两次读取时读取到的数据的状态是一致的，和序列化(SERIALIZABLE)可重复读中可能出现第二次读读到第一次没有读到的数据，也就是被其他事务插入的数据，这种情况称为幻读phantom read, 序列化级别中不能出现幻读。

隔离级别依次增强，但是导致的问题是并发能力的减弱。

各种数据库厂商会对各个隔离级别进行实现。

和 Java 中的多线程问题相同，数据库通常使用锁来实现隔离性。

最原生的锁，锁住一个资源后会禁止其他任何线程访问同一个资源。但是很多应用的一个特点都是读多写少的场景，很多数据的读取次数远大于修改的次数，而读取数据间互相排斥显得不是很必要。所以就使用了一种读写锁的方法，读锁和读锁之间不互斥，而写锁和写锁、读锁都互斥。这样就很大提升了系统的并发能力。之后人们发现并发读还是不够，又提出了能不能让读写之间也不冲突的方法，就是读取数据时通过一种类似快照的方式将数据保存下来，这样读锁就和写锁不冲突了，不同的事务session会看到自己特定版本的数据。当然快照是一种概念模型，不同的数据库可能用不同的方式来实现这种功能。

之后的讨论默认均以REPEATABLE READ作为隔离级别。

InnoDB与MVCC

MySQL中的InnoDB存储引擎的特性有，默认隔离级别REPEATABLE READ, 行级锁，实现了MVCC, Consistent nonlocking read(默认读不加锁，一致性非锁定读), Insert Buffer, Adaptive Hash Index, DoubleWrite, Cluster Index。

上面列举了这么多，表示InnoDB有很多特性、很快。

InnoDB中通过UndoLog实现了数据的多版本，而并发控制通过锁来实现。

Undo Log除了实现MVCC外，还用于事务的回滚。

Redo log, bin log, Undo log

MySQL Innodb中存在多种日志，除了错误日志、查询日志外，还有很多和数据持久性、一致性有关的日志。

binlog，是mysql服务层产生的日志，常用来进行数据恢复、数据库复制，常见的mysql主从架构，就是采用slave同步master的binlog实现的, 另外通过解析binlog能够实现mysql到其他数据源（如ElasticSearch)的数据复制。

redo log记录了数据操作在物理层面的修改，mysql中使用了大量缓存，缓存存在于内存中，修改操作时会直接修改内存，而不是立刻修改磁盘，当内存和磁盘的数据不一致时，称内存中的数据为脏页(dirty page)。为了保证数据的安全性，事务进行中时会不断的产生redo log，在事务提交时进行一次flush操作，保存到磁盘中, redo log是按照顺序写入的，磁盘的顺序读写的速度远大于随机读写。当数据库或主机失效重启时，会根据redo log进行数据的恢复，如果redo log中有事务提交，则进行事务提交修改数据。这样实现了事务的原子性、一致性和持久性。

Undo Log: 除了记录redo log外，当进行数据修改时还会记录undo log，undo log用于数据的撤回操作，它记录了修改的反向操作，比如，插入对应删除，修改对应修改为原来的数据，通过undo log可以实现事务回滚，并且可以根据undo log回溯到某个特定的版本的数据，实现MVCC。

MVCC实现

innodb中通过B+树作为索引的数据结构，并且主键所在的索引为ClusterIndex(聚簇索引), ClusterIndex中的叶子节点中保存了对应的数据内容。一个表只能有一个主键，所以只能有一个聚簇索引，如果表没有定义主键，则选择第一个非NULL唯一索引作为聚簇索引，如果还没有则生成一个隐藏id列作为聚簇索引。

除了Cluster Index外的索引是Secondary Index(辅助索引)。辅助索引中的叶子节点保存的是聚簇索引的叶子节点的值。

InnoDB行记录中除了刚才提到的rowid外，还有trx_id和db_roll_ptr, trx_id表示最近修改的事务的id,db_roll_ptr指向undo segment中的undo log。

新增一个事务时事务id会增加，trx_id能够表示事务开始的先后顺序。

数据可见性判断

CREATE TABLE `testunique` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `uid` int(11) DEFAULT NULL,
  `ukey` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `id_uid` (`uid`),
  KEY `index_key` (`ukey`)
) ENGINE=InnoDB AUTO_INCREMENT=70 DEFAULT CHARSET=utf8;
隔离级别REPEATABLE READ

session1	session2
begin;
	select * from testunique;
insert into testunique values(NULL, NULL, 1);
	select * from testunique;
commit
	select * from testunique;
	commit
	select * from testunique;

只有当session2 commit之后的查询才能查到session1插入的数据

Undo log删除

undo log在没有活动事务依赖（用于consistent read或回滚)便可以清楚，innodb 中存在后台purge 线程进行后台轮询删除undo log。

Current Read snapshot read

REPEATABLE READ隔离级别下普通的读操作即select都不加锁，使用MVCC进行一致性读取，这种读取又叫做snapshot read。

而update, insert, delete, select … for update, select … lock in share mode都会进行加锁，并且读取的是当前版本，也就是READ COMMITTED读的效果。 innodb-locks-set.html 中对各种操作会进行的锁操作有详细的说明，这里我简单总结下。

InnoDB中加锁的方法是锁住对应的索引，一个操作进行前会选择一个索引进行扫描，扫描到一行后加上对应的锁然后返回给上层然后继续扫描。InnoDB支持行级锁(record lock)，上述需要加锁的操作中，除了select … lock in share mode 是加shared lock（共享锁或读锁）外其他操作都加的是exclusive lock(即排他锁或写锁)。在加行级锁前，会对表加一个intention lock，即意向锁，意向所是表级锁，不会和行级锁冲突，主要用途是表明一个要加行级锁或正在加锁的操作。

另外InnoDB种除了record lock外还有一种gap lock，即锁住两个记录间的间隙，防止其他事务插入数据，用于防止幻读。当索引是主键索引或唯一索引时，不需要加gap lock。当索引不是唯一索引时，需要对索引数据和索引前的gap加锁，这种方式叫做next-key locking。

另外在插入数据时，还需要提前最插入行的前面部分加上insert intention lock, 即插入意向锁，插入意向锁之间不会冲突，会和gap锁冲突导致等待。当插入时遇到duplicated key错误时，会在要插入的行上加上share lock。

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

• Kubernetes 存储原理解析
• Git内部存储原理
• Git内部存储原理
• Kafka日志存储原理
• Git数据存储的原理浅析
• 架构视角：文件的通用存储原理

本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。