Blog

innodb存储引擎关键点

[TOC]

缓存池

• 索引页

• 数据页

• undo页

• 插入缓存

• 自适应哈希索引

• innodb引擎的锁信息

• 数据字典信息

mysql> use information_schema;                                                   Database changed
mysql> select pool_id,pool_size, free_buffers,database_pages from innodb_buffer_pool_stats \G;
*************************** 1. row ***************************
       pool_id: 0
     pool_size: 8192
  free_buffers: 1024
database_pages: 7160
1 row in set (0.00 sec)

缓存池管理

• LRU（默认）
  • 频繁使用的在LRU列表前端
  • 优化：新访问的页不是放在列表前端，而是放在Midpoint。避免扫描全表的sql，将热点数据挤压刷出
  • midpoint之前称为新表（new sublist），表示热点数据
  • midpoint之前称为旧表（old sublist）
• unzip_LRU
  • 管理非16KB的页
  • LRU列表中包含unzip_LRU列表中的页

  在LRU列表中的页被修改后，成改页为脏页（dirty page）。

  数据块通过checkpoint机制将脏页刷新回磁盘

  Flush列表中的页为脏页列表。脏页同时存在于LRU列表和Flush列表

重做日志缓存(redo log buffer)

• 先将redo信息放入redo log buffer
• 然后按照一定频率刷新到redo log file（一般1秒一刷）
• flush redo log
  • master thread 一秒刷redo log buffer to redo log
  • 每个事务提交时
  • 当redo log buffer 剩余空间少于1/2时

额外的内存池

• 一些数据结构本身的内存优先从（额外的内存池）中分配
• 当（额外的内存池）内存不足，会从缓存池中分配

checkpoint技术

面对的难题

• 缓存池不可能缓存数据库所有数据
• redo log不可能无限大

用于解决

• 缩短数据库恢复时间
• 缓冲池不够用时，将脏页刷新到磁盘
• 重做日志不可用时，刷新脏页

通过LSN（log sequence Number）来标记版本的。

• LSN是8字节的数字
• 每个页有LSN
• redo log有LSN
• checkpoint 有LSN

有两种checkpoint

• Sharp checkpoint，数据库关闭时，将所有脏页刷新回磁盘
• Fuzzy checkpoint，数据库运行中使用，进行页的刷新，只刷新一部分脏页回到磁盘
  • master Fuzzy checkpoint。异步定时从缓冲池刷脏页到磁盘
  • FLUSH_LRU_LIST Checkpoint 为了保证LRU LIST有差不多100个空闲页可供使用，Page Cleaner线程中执行
  • Async/Sync flush Checkpoint.
  • dirty page too much Checkpoint

MASTER THREAD

• 具有最高的线程优先级
• 由多个loop循环组成
  • 主循环（loop）：每秒操作和每十秒操作
  • 后台循环（backgroup loop）
  • flush loop
  • 暂停循环（suspend loop）

loop

每秒操作

• 刷redo log buffer到磁盘，即使这个事务还没有提交（总是）

  解析了为什么再大的事务commit都很快

• 合并插入缓冲（可能）

  只有io压力很低，前一秒的io总数<5,才会执行。

• 至多刷100个Innodb 缓冲池中的脏页到磁盘（可能）

  当前缓存池中的脏页比例buffer_get_modified_ratio_pct大于配置值

• 当前没有用户，切换到backupgroup loop状态（可能）

每十秒操作

• 刷100个Innodb 缓冲池中的脏页到磁盘（可能）
• 合并至多5个插入缓冲（总是）
• 刷redo log buffer到磁盘（总是）
• 删除无用的undo页（总是）
• 刷100或者10个Innodb 缓冲池中的脏页到磁盘（总是）

backupgroup loop

• 删除无用的undo页（总是）
• 合并20个插入缓冲（总是）
• 跳回主循环（总是）
• 不断刷100个Innodb 缓冲池中的脏页到磁盘（总是）（可能跳转到flush loop中完成）

InnoDB1.0.x之后

1.0.x版本之前，Master Thread 有了一定的hard coding。随着硬件性能日新月异，这对编码方式不能很好的匹配不同性能的硬件。

• 使用配置代替hard coding
• 增加了一些参数自适应

InnoDB1.2.x之后

刷新脏页的操作从Master Thread分离到一个独立的Page Cleaner Thread。减轻Master Thread 的工作，同时进一步提高了系统的并发性。

Innode关键特征

• insert buffer
• double write
• adaptive hash index
• async IO
• Flush Neighbor Page

insert buffer

insert buffer 和数据页一样，也是物理页的一个组成部分，用于非唯一辅助索引的插入操作。

每一张表上除了有一个聚集索引（primary key），有可能还有多个非聚集的辅助索引。

在进行插入操作的时候，数据页还是按照primary key进行顺序存放的。但是对于非聚集索引叶子节点的插入不再是顺序的。这时需要离散的访问非聚集索引页，由于随机读取的存在，进而影响了插入性能。

mysql引入insert buffer，对非聚集索引的插入或更新操作，不是每一次直接插入到索引页中，而是先判断插入的非聚集索引页是否在缓冲池中，若是在，则直接插入；若不在，则先放入到一个insert buffer对象中。

然后再以一定的频率和情况进行insert buffer和辅助叶子节点的merge操作。

辅助索引不能是唯一的，因为在插入缓冲时，数据库为了避免离散读取的情况发生，并不去查找索引页来判断插入的记录的唯一性。

Change Buffer

Innodb 1.0.x版本开始引入Change Buffer，可将其视为Insert BUFFER的升级。Innodb可以对DML操作–INSERT、DELETE、UPDATE都进行缓冲，它们分别是：

• Insert Buffer
• Delete Buffer
• Purge Buffer

Innodb 提供参数Innodb_change_bufferiing,用于开启各种Buffer的选项

对一条记录进行UPDATE操作可能分为连个过程：

• Delete buffer复制将记录标记为删除

• Purge buffer负责将记录真正的删除

Insert Buffer的内部实现

• 使用b+树

  mysql 4.1之前每张表有一颗insert buffer B+树。现在全局只有一颗Insert Buffer B+树

• 它保存在共享空间中（ibdata1），因此，试图通过独立表空间ibd文件恢复表中数据时，往往会导致CREATE TABLE失败。这是因为表的辅助索引中的数据可能还在Insert Buffer中。所以通过idb文件进行恢复后，还需要进行REPAIR TABLE操作来重建表上所有的辅助索引。

• 由叶子节点和非叶子节点组成

• 非叶子节点存放的是查询的search key（键值）,结构如下

space	marker	offset
表示待插入记录所以在表的表空间id	用于兼容向后兼容	页所在的偏移量

• 当一个辅助索引要插入到页（space，offset）时，如果这个页不再缓冲池中，那么Innodb首先根据上述规则构造一个search key，接下来查询insert buffer，然后将记录插入到insert buffer B+树的叶子节点中。

space	：marker	offset	metadata	–	–	–	–

• metadata中IBUF_REC_OFFSET_COUNT（2字节的整数）用来排序每个记录进入insert buffer的顺序

• insert buffer bitmap：一个特殊的页，用来标记每个辅助索引页的可用空间，保证每次merge insert buffer页必须成功。

• 每个insert buffer bitmap用来追踪16384个辅助索引页，也就是256个区（Extent）

• 每个辅助索引页在insert buffer bitmap中存储结构

  

merge insert buffer

• 辅助索引页被读取到缓冲池中
  • 检查insert buffer bitmap页，确认该辅助索引页是否存放在insert buffer B+树中
  • 存在，则将B+树中该页的记录插入到该辅助索引页中。对该页多次的记录操作通过一次合并到原有的辅助索引页
• insert buffer bitmap页追踪到该辅助索引页已无可用空间时。（小于1/32页，会强制进行一次合并操作）
• Master Thread中每秒或者每十秒的合并操作。

两次写

避免数据库宕机时，出现部分写失效（partial page write）。例如某个页16KB，只写了4KB就发生了宕机。

通过redo log进行数据恢复，由于redo日志记录的是对页的物理操作（如偏移量800，写‘aaa’记录），需要基于页是好的。如果这个页本身已经发生了损坏，无法通过redo 日志进行重放。

doublewrrite：当写入失效发生时，先通过页的副本还原该页，再进行重做。

doublewrrite由两部分组成：

• 内存中的doublewrrite buffer，2MB
• 物理磁盘上共享表空间中连续的128个页，即2个区（extent），2MB

在对缓冲池进行flush时，并不是通过写磁盘，而是通过memcpy函数将脏页先复制到内存中的doublewrite buffer，之后通过doublewrite buffer再分两次，每次写1MB顺序写入共享表空间的物理磁盘上，然后马上调用fsync函数，同步磁盘避免缓冲写带来的问题（顺序写）。doublewrite buffer中的页写入到各个表空间文件中。（离散写）

自适应哈希索引（AHI）

自适应哈希索引：Innodb存储引擎会监控对表上各索引的查询，如果观察到建立哈希索引可以带来速度提升，则建立哈希索引。

AHI是通过缓冲池的B+树页构造，不需要对整张表构建哈希索引。

条件：

• 访问模式一样，即查询的条件一样。
• 以该模式访问了100次
• 页通过该模式访问了N次，其中（N=页中记录*1/16）。

异步IO

Innodb支持AIO。

• read ahead 方式的读取（借助aio，将所有io发送完毕后，然后等待所有IO操作的完成）
• 脏页的刷新（可以将多个连续io进行IO Merge）

刷新邻近页

当刷新一个脏页时，Innodb会检测改页所在区（extent）的所有页，如果是脏页，那么一起进行刷新。然后通过AIO将多个io写入操作合并成一个IO操作。

缺点：

• 可能会将不怎么脏的页进行了写入，而该页之后很快又会变成脏页。
• 固态硬盘有着较高的IOPS，不需要这个特性。

下面是bitcask的论文里，作者考虑到的目标

• low latency per item read or written
• high throughput, especially when writing an incoming stream of random items
• ability to handle datasets much larger than RAM w/o degradation
• crash friendliness, both in terms of fast recovery and not losing data
• ease of backup and restore
• a relatively simple, understandable (and thus supportable) code structure and data format
• predictable behavior under heavy access load or large volume
• a license that allowed for easy default use in Riak

论文地址：https://riak.com/assets/bitcask-intro.pdf