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,不需要这个特性。
Leave a Reply