MySQL数据库进阶第六篇（InnoDB引擎架构，事务原理，MVCC）

文章目录

一、InnoDB引擎逻辑储存结构
二、架构------内存结构
三、架构------磁盘结构
四、架构------后台线程
五、事务原理
- [持久性：redo log。重做日志](#持久性：redo log。重做日志)
- [原子性：undo log。回滚日志](#原子性：undo log。回滚日志)
六、MVCC基本概念
七、MVCC实现原理
[八、undo log日志回滚日志，版本链](#八、undo log日志回滚日志，版本链)
[九、readView 读视图决定查询读取的记录](#九、readView 读视图决定查询读取的记录)

本文将带您遍览 InnoDB 存储引擎的内部机制，深入其逻辑存储结构和内存架构，解析页、段、区至行的层级，揭秘索引与数据是如何存放的。深入缓冲池的秘密，发现 InnoDB 如何以 Buffer Pool 为纽带，缓解物理硬盘与内存间的速度差异，保持高效。掌握更改缓冲区的智慧，理解非唯一二级索引背后的故事。嗅探自适应哈希索引和日志缓冲区，探寻其提升查询与事务写入的神奇之处。
文章还展现了 InnoDB 独特的磁盘结构布局，包含一应俱全的系统表空间、表级空间和特有的回滚机制，为数据的持久化与安全性搭建了坚实的基础。揭示了后台线程如何无声地协助数据在内存和磁盘间舞动，以及事务原理的严密逻辑，事务的 ACID 特性在 InnoDB 中如何实现。
最后，本文还深入探讨了 MVCC 的实现原理和细节，通过生动的快照读和 ReadView 机制，让并发控制如丝般顺滑，值得每位数据库爱好者细细品味。

一、InnoDB引擎逻辑储存结构

段，分为数据段、索引段、回滚段，InnoDB是索引组织表，数据段是B+树的非叶子结点，段用来管理多个区

区，表空间的单元结构，每个区大小为1M，默认情况下InnoDB存储引擎页大小为16K，即一个区公共有64个连续的页

页，是InnoDB存储引擎磁盘管理的最小单元，每个页的大小默认为16KB。为了保证页的连续性，每次InnoDB都会向磁盘申请4-5个区

行，InnoDB存储引擎数据是按照行进行存放的

记录中的每一列col1，col2，col3

两个隐藏列

Trx id，最后一次操作该行的事务ID

Roll pointer，每次对改行记录进行改动时，会把旧版本写入undo日志中，该值是指针，通过它可以找到之前没有改动的旧版本

二、架构------内存结构

InnoDB存储引擎基于磁盘文件存储，在物理硬盘和在内存中的速度相差很大，为了尽可能弥补这两者之间的I/O效率的差值，就需要把经常使用的数据加载到缓冲池中，避免每次访问都进行非常慢的且大部分都是随机的磁盘I/O。

在InnoDB的缓冲池中不仅缓存了索引页和数据页，还包含了undo页、插入缓存、自适应哈希索引以及 InnoDB的锁信息等等。
## Buffer Pool缓冲池

缓冲池 Buffer Pool，是主内存中的一个区域，里面可以缓存磁盘上经常操作的真实数据，在执行增删改查操作时，先操作缓冲池中的数据（若缓冲池没有数据，则从磁盘加载并缓存），然后再以一定频率刷新到磁盘，从而减少磁盘IO，加快处理速度。

缓冲池以Page页为单位，底层采用链表数据结构管理Page。根据状态，将Page分为三种类型：

free page：空闲page，未被使用

clean page：被使用page，数据没有被修改过

dirty page：脏页，被使用page，数据被修改过，页中数据与磁盘的数据产生了不一致
## Change Buffer 更改缓冲区（针对于非唯一的二级索引页）

在执行DML（数据增删改）语句时，如果这些数据Page 没有在Buffer Pool中，不会直接操作磁盘，而会将数据变更存在更改缓冲区 Change Buffer 中，在未来数据被读取时，再将数据合并恢复到Buffer Pool中，再将合并后的数据以一定频率刷新到磁盘中。

意义：与聚集索引不同，二级索引通常是非唯一的，并且以相对随机的顺序插入二级索引。同样，删除和更新可能会影响索引树中不相邻的二级索引页，如果每一次都操作磁盘，会造成大量的磁盘IO。有了 ChangeBuffer之后，我们可以在缓冲池中进行合并处理，减少磁盘IO

## Adaptive Hash Index 自适应哈希索引

用于优化对Buffer Pool数据的查询。MySQL的innoDB引擎中虽然没有直接支持 hash索引，但是提供功能，即自适应hash索引。

hash索引对于等值匹配，一般性能高于B+树，因为hash索引一般只需要一次IO即可，而B+树可能需要几次匹配，所以hash索引的效率要高，但hash索引又不适合做范围查询、模糊匹配等。

因此InnoDB存储引擎会监控对表上各索引页的查询，如果观察到在某条件下hash索引效率更高，则建立hash索引，称为自适应hash索引。自适应哈希索引无需人工干预，是系统根据情况自动完成。

## Log Buffer 日志缓冲区

Log Buffer：日志缓冲区，用来保存要写入到磁盘中的log日志数据（redo log 、undo log），默认大小为 16MB，日志缓冲区的日志会定期刷新到磁盘中。如果需要更新、插入或删除许多行的事务，增加日志缓冲区的大小可以节省磁盘 I/O。

参数：innodb_log_buffer_size：缓冲区大小

参数：innodb_flush_log_at_trx_commit：日志刷新到磁盘时机，取值主要包含以下三个：

1日志在每次事务提交时写入并刷新到磁盘，默认值

0: 每秒将日志写入并刷新到磁盘一次

2: 日志在每次事务提交后写入，并每秒刷新到磁盘一次

三、架构------磁盘结构

磁盘结构

## System Tablespace 系统表空间

是更改缓冲区Change Buffer 的存储区域。如果表在系统表空间而不是每个表文件或通用表空间中创建的，它也可能包含表和索引数据。(在MySQL5.x版本中还包含InnoDB数据字典、undolog等)
## File-Per-Table Tablespaces

每张表的独立表空间，则每个表的文件表空间包含单个InnoDB表的数据和索引，并存储在文件系统上的单个数据文件中。一个.ibd 对应一个表
## General Tablespaces 通用表空间

需要通过 CREATE TABLESPACE 语法创建通用表空间，在创建表时，可以指定该表空间

c 复制代码

#创建表空间
CREATE TABLESPACE ts_name ADD DATAFILE 'file_name' ENGINE = engine_name;
#创建表时指定表空间
CREATE TABLE xxx ... TABLESPACE ts_name;
#-----------举例-----------
create tablespace ts_01 add datafile 'mydb01.ibd' engine = innodb;
创建表空间成功后，后续创建表时 可以指定把表创建至该表空间里

## Undo Tablespaces 撤销表空间

撤销表空间，MySQL实例在初始化时会自动创建两个默认的undo表空间（初始大小16M），用于存储 undo log日志，undo_001, undo_002

## Temporary Tablespaces 临时会话表空间

InnoDB 使用会话临时表空间和全局临时表空间。存储用户创建的临时表等数据。
## Doublewrite Buffer Files 双写缓冲区

双写缓冲区，innoDB引擎将数据页从Buffer Pool刷新到磁盘前，先将数据页写入双写缓冲区文件中，便于系统异常时恢复数据

## Redo Log 重做日志

用来实现事务的持久性。该日志文件由两部分组成：重做日志缓冲区（redo log buffer）（在内存结构的Log Buffer中）以及重做日志文件（redo log），前者是在内存中，后者在磁盘中。

当事务提交之后会把所有修改信息存到该日志中，用于在刷新脏页到磁盘发生错误时，进行数据恢复使用。以循环方式写入重做日志文件，涉及两个文件

四、架构------后台线程

内存中的数据和磁盘的数据是怎么写入和读取的呢？后台线程

## Master Thread（核心后台线程）：

是MySQL的一个核心后台线程，负责管理和协调其他后台线程的工作，并将缓冲池中的数据异步刷新到磁盘中，保持数据的一致性；脏页的刷新、合并插入缓存、undo页的回收

## IO Thread（读写线程）：

异步非阻塞IO 极大地提高数据库的性能，这些线程负责处理InnoDB存储引擎的IO请求，包括读取和写入磁盘上的数据。

## Purge Thread（清理线程）：

Purge Thread负责回收已完成提交事务的undo log，将其释放以供后续事务使用。

## Page Cleaner Thread（页清理线程）：

该线程负责在InnoDB存储引擎中执行脏页的刷新操作，将脏页写回磁盘，以确保数据的持久性和一致性。协助Master Thread。

五、事务原理

事务：一组操作的集合，要么全部成功，要么全部失败：

事务的四大特性：（ACID）原子性，一致性，隔离性，持久性

A：事务是不可分割的最小操作单元，要么全部成功，要么全部失败

C：事务完成时，必须使所有的数据都保持一致状态

I：数据库系统提供的隔离机制，保证事务在不受外部并发操作影响的独立环境下运行

D：事务一旦提交或回滚，它对数据库中的数据的改变就是永久的

持久性：redo log。重做日志

记录事务提交时，对数据页的物理修改，实现事务的持久性

包含两部分：重做日志缓冲（内存结构中的Log Buffer）与磁盘的重做日志文件，提交后会把所有修改信息保存到该文件中，用于当刷新脏页到磁盘发生错误时进行数据恢复使用

update/delete执行：

先看内存的BufferPool中有没有该页，如果没有该页则通过后台线程从磁盘中把页读到Buffer Pool

直接操作缓冲区中的数据，该页变成脏页

首先把数据页的物理变化记录在内存中的RodoLogBuffer，commit 事务提交的时候，redologBuffer会直接把数据页变化刷新到磁盘当中，即ib_logfile0，ib_logfile1中

在某个时机该页以一定频率刷新到磁盘中进行持久化，若此时出错，则可以通过磁盘文件中的redo_log进行数据恢复

若脏页顺利写入磁盘，则redolog文件就不再需要，因此每过一段时间就清理一次redo log日志，是循环性的，不是永久的

日志文件都是追加的，是顺序磁盘I/O，效率比数据在磁盘的随机存取快速的多

WAL 先写日志 Write-Ahead Logging

原子性：undo log。回滚日志

用于记录被修改前的信息，作用包括两个：提供回滚和 MVCC（多版本并发控制）

undo log 和 redo log 记录的物理日志不一样，它是逻辑日志。可以认为当delete一条记录时，undo log会记录一条对应的insert记录，反之亦然，当update一条记录时，它记录一条对应相反的 update记录（执行update之前数据长的样子）。当执行rollback时，就可以从undo log中的逻辑记录读取到相应的内容并进行回滚

Undo log 销毁：undo log在事务执行时产生，事务提交时，并不会立即删除undo log，因为这些日志可能还用于MVCC

Undo log 存储：undo log采用段的方式进行管理和记录，存放在段中的rollback segment 回滚段中，内部包含1024个undo log segment

六、MVCC基本概念

当前读：读取的是记录的最新版本，读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加锁。对于我们日常的操作，如：select ... lock in share mode(共享锁)，select ... for update、update、insert、delete(排他锁)都是一种当前读。

客户端1使用select 语句，客户端2使用 update语句进行更新，因为当前隔离级别是可重复读，因此客户端1无法看到客户端2事务对数据的更改