mvcc原理_MySQL MVCC实现原理

1.Mysql特点

可靠、事务、开源。

2.MySQL架构

接入层，连接通信、权限验证、连接池、线程管理

服务层，sql解析器、sql优化器、数据缓冲、缓存等

存储引擎层，存储机制、索引技巧、锁定水平，增删改查

系统文件层，保存数据、索引、日志

3.ACID

原子性：一个事务的操作要不全部执行，要么全部不执行

一致性：一个事务总是从一个一致性状态转换到另外一个一致性状态

隔离性：一个事务的修改结果什么时候能被其他事务看到。(SQL1992规范中对隔离性定义了不同的隔离级别)

持久性：事务一旦提交，其结果就是永久性的

4.事务的隔离级别

读未提交(Read Uncommitted):可能读取到其他会话中未提交事务修改的数据(脏读)

读已提交(Repeatable Read)：只能读取到已经提交的数据(幻读、不可重复读)

可重复读(Repeatable Read)：在同一个事务内的查询都和事务开始时刻一致(幻读) ---百度百科)

串行读(Serializable):提供严格的事务隔离。它要求事务序列化执行，事务只能一个接着一个地执行，不能并发执行。仅仅通过“行级锁”是无法实现事务序列化的，必须通过其他机制保证新插入的数据不会被刚执行查询操作的事务访问到。 ---百度百科

==*一般隔离级别越强，并发能力越弱==

5.原生的锁

缺点：互斥

数据库场景：读多写少

==*因此需要读写锁！==

6.读写锁

读读不互斥，读写、写写互斥。

==*能不能让读写不互斥呢？因此有了多版本控制，不同事务session看到自己特定版本的数据。==

7.innoDB简介

特点：行级锁、默认隔离级别为Repeatable Read、实现了MVCC、一致性非锁定读、insert buffer、double write、cluster index。

8.innoDB的主要日志介绍

binlog：服务层生产日志，数据恢复、数据库复制

redo log：数据在物理层面的修改，断电恢复、保证一致性和持久性，顺序 ：写入数据->redo log buffer->file system buffer->fsync操作->redo log file ->commit

为什么要先写入redo log?

redo log是顺序读写，远大于随机读写速度。

undo log：事务回滚、实现MVCC

*bin log 和redo log的一致性，通过两阶段提交：

InnoDB prepare (持有prepare_commit_mutex)；

write/sync Binlog；

InnoDB commit (写入COMMIT标记后释放prepare_commit_mutex)。

9.innoDB索引介绍

数据结构：B+tree

聚集索引，主键使用聚集索引，叶子节点保存了具体的数据内容；如果未指定主键，则以第一个非null唯一索引作为聚集索引。若还没有则声称一个隐藏列rowid。

==*一个表只有一个聚集索引。==

辅助索引：叶子节点data域存储相应的主键值

10.innoDB MVCC的实现原理

innoDB的mvcc主要是为了Repeatable-Read隔离级别实现的。

限制：MVCC只在RR和RC隔离级别下工作，其他两个隔离级别不兼容。RU读的是最新版本的数据。不符合当前事务版本的数据行，而Serializable对所读取的行加锁。

10.1 隐含字段

6-byte DB_TRX_ID:最新更新这行记录的事务ID

7-byte DB_ROLL_PTR:指向rollback segment 的undo log记录的指针

6-byte DB_ROW_ID:innoDB自动产生聚集索引是，data域包含该值，否则不包含改值

特殊字段 DELETE BIT：标志是否删除(真正删除是在COMMIT时)

10.2 行的更新过程

1.初始数据行：

[图片上传失败...(image-b4b953-1535684919327)]

2.事务1更新该行的值：

[图片上传失败...(image-9120ec-1535684919327)]

当事务1更改该行的值时，会进行如下操作：

用排他锁锁定该行

记录redo log

把该行修改前的值Copy到undo log，即上图中下面的行

修改当前行的值，填写事务编号，使回滚指针指向undo log中的修改前的行

3.事务2更新该行的值：

[图片上传失败...(image-d25ed5-1535684919327)]

此时undo log中存在两条记录，并通过回滚指针连在一起。

若回滚，根据回滚指针从undo log找出事务修改前的版本并恢复。

若提交，更改事务状态为COMMIT,其他什么都不做(见下面的具体操作)

==* 若事务影响的行数比较多，那么回滚的性能也很低。==

10.3 具体操作过程

SELECT

Innodb检查每行数据，确保他们符合两个标准：

1.InnoDB只查找版本早于当前事务版本的数据行(也就是数据行的版本必须小于等于事务的版本)，这确保当前事务读取的行都是事务之前已经存在的，或者是由当前事务创建或修改的行

2.行的删除操作的版本一定是未定义的或者大于当前事务的版本号，确定了当前事务开始之前，行没有被删除

符合了以上两点则返回查询结果。

==具体的结果是否要根据readview的规则？==

INSERT

InnoDB为每个新增行记录当前系统版本号作为创建ID。

DELETE

InnoDB为每个删除行的记录当前系统版本号作为行的删除ID。

UPDATE

InnoDB复制了一行。这个新行的版本号使用了系统版本号。它也把系统版本号作为了删除行的版本。