MYSQL数据库——InnoDB存储引擎

一.逻辑存储结构

二.架构

1.内存结构

1.缓冲池（buffer_pool）

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

缓冲池以page页为单位，底层采用链表数据结构管理page，根据状态可将page分为：

①free page：空闲page，未被使用

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

③dirty page：脏页，被使用page，数据被修改过，数据与磁盘的数据不一致。

• 缓冲池 Buffer Pool 用于加速数据的访问和修改。
• 默认大小 128 M
• 缓存数据到内存，最大限度地减少磁盘 IO，加速 热点数据 的读和写
• 使用 **LRU 算法（最近最久未使用）**淘汰非热点数据页
• LRU：根据页数据的历史访问来淘汰数据，如果数据最近被访问过，那么将来访问的几率也更高，优先淘汰最近没有被访问到的数据
• Buffer Pool 中的数据以 页 为存储单位，数据结构是 单链表
• 对于 Buffer Pool 中数据的「查询」，InnoDB 直接读取返回；
• 对于 Buffer Pool 中数据的「修改」，InnoDB 直接在 Buffer Pool 中修改，并将修改写入 redo Log 中，当数据页被 LRU 算法淘汰时写入磁盘，若持久化前系统崩溃，则在重启后使用 redo Log 进行恢复。

2.修改缓冲区（change buffer）

Change Buffer 针对于非唯一二级索引页，在执行DML语句时，如果这些数据Page没有在Buffer Pool中，不会直接操作磁盘，而会将数据变更存在更改缓冲区（Change Buffer）中，在未来数据被读取中，再将数据合并恢复到Buffer Pool中，再将合并后的数据刷新到磁盘中。

Change Buffer存在的意义：

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

3.自适应hash索引（Adaptive Hash Index）

自适应hash索引用于优化对Buffer Pool数据的查询，InnoDB存储引擎会监控对表上各索引页的查询，如果观察到hash索引可以提升速度，则建立hash索引。

无需人工干预，是系统根据情况自动完成。

4.日志缓冲区（Log Buffer）

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

2.磁盘结构

在磁盘中，InnoDB 存储引擎将 数据、索引、表结构和其他缓存信息等 存放的空间称为 表空间（Tablespace），它是 物理存储中的最高层，由 段Segment、区Extent、页Page、行Row 组成。

目前的表空间类别包括：

• 系统表空间（System Tablespace），关闭独立表空间，所有表数据和索引都会存入系统表空间
• 独立表空间（File-per-table Tablespace），开启独立表空间，每张表的数据都会存储到一个独立表空间
• 通用表空间（General Tablespace）
• 回滚表空间（Undo Tablespace）
• 临时表空间（The Temporary Tablespace）

双写缓冲区（doublewrite Buffer Files）：InnoDB存储引擎将数据页从Buffer Pool刷新到磁盘前，先将数据写入该缓冲区，便于系统异常时恢复数据。

重做日志（redo Log）：用来实现事务的持久性，分为重做日志缓冲（redo log buffer）以及重做日志文件（redo log），前者是在内存中，后者在磁盘中，当事务提交后会把所有修改信息都保存到该日志中，用于在刷新脏页到磁盘时，发生错误时，进行数据恢复使用。

3.后台线程

1.Master Thread

核心后台线程，负责调度其他线程，还负责将缓冲池中的数据异步刷新到磁盘中，保持数据的一致性，还包括脏页的刷新，合并插入缓存，undo页的回收

2.IO Thread

在InnoDB中大量使用了AIO来处理IO请求，这样可极大提高数据库的性能，IO thread主要负责这些IO请求的反馈。

3.Purge Thread

主要用于回收事务已提交的undo log，在事务提交后，undo log可能不用了，就通过它来回收

4.Page Cleaner Thread

协助Master Thread刷新脏页到磁盘的线程，可减轻Master Thread的工作压力，减少阻塞。

三.事务原理

1.redolog

重做日志记录的是事务提交数据页的物理修改，用来实现事务的持久性，分为重做日志缓冲和重做日志文件，前者在内存中，后者在磁盘中，当事务提交后把所有修改信息都存到改日志文件中，用于在刷新脏页到磁盘发生错误时，进行数据恢复使用。

2.undo log

回滚日志，用来实现事务的原子性。用于记录数据被修改前的信息，作用：①提供回滚②MVCC（多版本并发控制）

undo Log是记录逻辑日志（redo log记录物理日志），可认为当delete一条记录时，undo log会记录一条对应的insert记录，当update一条记录时，记录一条对应相反的update记录，当执行rollback时，就可以从redo log中的逻辑记录读取到相应的内容并进行回滚。

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

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

redo Log 和undo Log保证了事务的一致性

三.MVCC

• 当前读：读取的是记录的最新版本，读取时需保证其他并发事务不能修改当前记录，会对读取的记录进行加锁，对于我们的日常操作，如：select...lock in share mode(共享锁），select...for update、update、insert、delete（排他锁）都是当前读。
• 快照读：简单的select(不加锁）就是快照读，快照读记录的是记录数据的可见版本，有可能是历史数据，不加锁，是非阻塞读。
• Read Committed：每次select 生成一个快照读。
• Repeatable Read：开启事务后的第一个select语句才是快照读的地方
• Serializable：快照读会退化为当前读

MVCC指维护一个数据的多个版本，使得读写操作没有冲突，快照读为MYSQL实现MVCC提供了一个非阻塞读功能。MVCC的具体实现，还需要依赖于数据库记录中的三个隐式字段、undo log日志、readView。

MVCC+锁保证了事务的隔离性

1.隐式字段

2.undolog版本链

当insert操作时，产生的undo log日志只在回滚时需要，在事务提交后可立即删除。

当update，delete操作时，产生的undo log日志不仅在回滚时需要，在快照读时也需要，不会立即被删除。

不同事务或相同事务对同一记录进行修改，会导致该记录的undolog生成一条记录版本链表，链表的头部是最新的旧记录，链表尾部是最早的旧记录。

3.readView

readView（读视图）是快照读SQL执行时MVCC提取数据的依据，记录并维护系统当前活跃的事务（未提交的）id，readView包含四个核心字段：

不同的隔离级别，生成的readView的时机不同：

• Read Committed：在事务中每一次执行快照读时生成ReadView。
• Repeatable Read：仅在事务中第一次执行快照读时生成ReadView，后续复用该ReadView。

4.原理分析

在RC级别下，事务中每一次执行快照读都会生成ReadView：

2.RR级别下，仅在食物中第一次执行快照读时生成ReadView,后续复用该ReadView：