InnoDB体系结构

简介

• innodb是基于表的存储引擎
• 支持事务，行锁设计，mvcc，外键，提供一致性非锁定读 。

1:概览

InnoDB存储引擎主要包含后台线程和内存池，内存池的主要又是缓冲池。

• 后台线程主要进行内存和磁盘之间双向的数据刷新
• 内存主要缓存磁盘上的数据

2:后台线程

2.1:Master thread

主要将缓冲池中的数据异步刷新到磁盘，包括脏页的刷新等

2.2:IO thread

2.3:Purge thread

3:内存

内存主要包含缓冲池

3.1:缓冲池

InnoDB存储引擎是基于磁盘的，并将其的记录按照页的方式进行管理。但是由于CPu读取速度和磁盘速度之间的差距，需要使用缓冲池来提升数据库的性能

读取与修改

在数据库中进行读取页的操作时，首先讲从磁盘读取到的页存放到缓冲池中，这个过程称为“FIX”在缓冲池中。下一次再读取相同的页时，首先判断该页是否在缓冲池中。若在缓冲池中，称该页在缓冲池中被命中，直接读取该页。否则，读取磁盘上的页。

要对数据库的数据进行修改时，先要修改缓冲池中页，然后再在合适的时候刷新到磁盘。注意并不是修改后就刷新到磁盘，而是通过一种称为Checkpoint的机制刷新回磁盘。

缓冲池大小设置

通过参数innodb_buffer_pool_size来进行设置。

多个缓冲池实例

现在可以通过参数innodb_buffer_pool_instances来设置缓冲池的实例。每个页可以根据哈希值平均分配到多个实例中，可以增强数据库的并发处理能力。

3.2:缓冲池的管理

LRU

维护一个LRU列表进行管理，使用LRU算法

普通LRU：最近最少使用算法，即最频繁使用的页在列表的前端，最少使用的页在列表的尾端。当缓冲池不能存放新读取到的页时，将首先释放尾端的页来腾出空间。

LRU列表

InnoDB中的LRU经过了两处优化

• 加入了midpoint位置
  新读取到的页不加入到LRU列表的头部，而是加入到midpoint对应的位置默认配置下midpoint在5/8处。可以由参数innodb_old_blocks_pct控制。
  我们将midpoint前的位置称为new区域（热数据区域），midpoint后的位置称为old区域（冷数据区域）。
  可以防止热数据被夸你只在本次查询中使用的页挤出去
• 加入了参数innodb_old_blocks_time。
  用于表示页读取到midpoint位置后多久才能加入到热数据区域。只有才超过这个时间之后，这个页再次被访问，才能倍加入到热数据区域。
  防止了一些只在这个时间内访问的页占满列表，来保护热数据区域。这个时间默认时一秒。

当页从冷数据区域啊计入到热数据区域时，称此发生的操作为page made young，因为时间的设置，不能从冷数据区域加入到热数据区域的操作称为page not made young。

注意LRU列表并不能维护缓冲池中所有类型的页，（应该是只管理数据页和索引页？）所以会看到free列表和LRU列表的页数量和不等于缓冲池总大小。

在数据库刚启动的时候LRU是空的，里面没有任何页。这时的页都存放在free列表中。

free列表

该列表存放的是空闲页。

当需要从缓冲池分页时，首先从free列表中查询有没有可用的空闲页，如果有就从free列表中删除，加入到LRU列表中。否则根据LRU算法，淘汰LRU列表末尾的页，将该内存空间分给新的页使用过。

可以通过SHOW ENGINE INNODB STATUS来查看LRU列表及FREE列表的使用情况和运行状态。

flush列表

在LRU中的页倍修改过后，称该页为脏页，即缓冲池中的页和磁盘上的页的数据产生了不一致。这时数据库会通过CHECKPOINT机制将脏页刷新到磁盘。

而Flush列表中的页即为脏页列表。

需要注意的是，脏页即存在于LRU列表中，也存在于Flush列表中。

压缩页

后面版本支持压缩页的功能，原本16KB的页页压缩到1KB，2KB，4KB，8KB。

对于非16KB的页使用unzip_LUR进行管理。但是要注意LRU列表中的页包含了unzip_LRU中的页。

管理方法：

• 在unzip_LRU列表中对不同压缩页大小的页进行分别管理
  也就是不同大小的页游不同的unzip_LRU进行管理。
• 通过伙伴算法进行内存的分配
  例如申请页为4KB的大小的空闲页：
  1:检查4KB的unzip_LRU列表查看是否有空闲页。若有就直接使用
  2:否则，检查8KB的unzip_LRU列表；
  3:若可以找到空闲页，就将页分成两个4KB的空闲页，存放到4KB的unzip_LRU列表中。
  4:若不能找到8kB的空闲页，从LRU列表申请一个16KB的空闲页（LRU可以从free列表中拿，或者使用LRU算法的到一个空闲页），将页分成一个8KB和两个4KB的空闲页，分别加入到对应的列表中去。

其他

缓冲池的命中率应该不小于百分之95.
看一看书上28页对缓冲池运行状态的数据分析。

3.3:重做日志缓冲

InnoDB现将重做日志信息放到这个缓冲区然后再刷新到重做日志文件。不需要很大，基本每秒就会刷新一次。
每个事务提交时回刷新一次，master线程每秒刷新一次。重做日志缓冲池空间小于一半也会刷新。

3.4:额外的内存池

一些数据结构本身的内存分配时，需要从额外的内存池中申请空间

4:checkpoint技术

• 主要发生在lru末尾脏页溢出
• 重做日志缓冲不够了。

理解。检查点技术是为了提高效率。执行检查点技术时，将一部分脏页刷新会磁盘，那么磁盘页的LSN就会发生改变，检查点的LSN也会发生改变，但是重做日志的LSN应该是不会发生改变。

4.1：原理

如果每次页发生了变化就刷新到磁盘，那么这个开销非常大。同时如果数据库宕机数据就不能恢复了。

为了避免数据丢失的问题，数据库普遍在食物提交前，先写重做日志，再修改页。当数据库宕机时，通过重做日志来完成数据的恢复。

check point技术主要用来解决以下几个问题：

• 缩短数据库恢复时间
• 缓冲池不够用时，将脏页刷新到磁盘
• 重做日志（磁盘中的，不是缓冲）不可用时，刷新脏页到重做日志的位置。

当数据库宕机时，数据库不需要重做所有日志，因为检查点之前的页都刷新回了磁盘。故数据库只需要对检查点之后的重做日志进行恢复。这样就大大缩短了恢复时间

当缓冲池不够用时，根据LRU算法回溢出最少使用的页，若此页时脏页，那么需要强制执行check point，将脏页刷新回磁盘

重用日志不可用出现的情况是因为现在的重做日志都是循环使用的，并不是让其无限增大的。重做日志可重用的部分是指这些重做日志不再被需要，即数据库宕机时，恢复数据不需要这些重做日志，也就是这些重做日志都是检查点之前的，没用了，因此这部分就可以本覆盖重用。如果重做日志还需要被使用，那么此时必须check point，将缓冲池中的页至少刷新到当前重做日志的位置

4.2:版本管理

使用LSN进行版本的标记

4.3:两种checkpoint

sharp checkpoint

发生在数据库关闭时将所有脏页都刷新回磁盘。InnoDB不使用这种。

因为他会影响数据库的性能，而且还需要很大的内存进行缓冲。

fuzzy check point

每次只刷新一部分脏页，而不是全部
以下几种浅咖u那个将会发生check point：

• master线程每秒或者十秒刷新一部分脏页到磁盘
• 缓冲池不够用时，末尾页如果是脏页
• 重做日志无可用部分时
• 脏页太多时，会强制刷新

5:InnoDB关键特性

两次写

因为可能脏页刷新回C盘的时候宕机，这时候页没有写完，这时候是破坏了页结构。

而且这时候重做日志缓冲没有用，因为使用重做日志的条件是页结构没有被破环

这时候就需要两次写了。

当脏页刷新回数据库C盘时，先不字节刷新回去，而先保存到共享表空间。再刷新回数据库磁盘。如果这时候宕机了。就用共享表空间的页恢复数据库磁盘中的页结构，再应用重做日志缓冲。

如果写入共享表空间的时候就宕机呢？那么可以字节用重做日志缓冲进行恢复，因为数据库对应的页又没有被破坏

注意，在刷新脏页之前，重做日志缓冲肯定已经刷新到了数据库