首页  思维导图  详情

InnoDB总结

2023-04-23 09:42:13   0  举报





AI智能生成

总结Inndb

数据库

mysql

innodb

作者其他创作

大纲/内容

体系架构

后台线程

Master Thread

分类

主循环

刷新循环

后台循环

暂停循环

时间频率

每秒

每十秒

IO Thread

负责IO请求处理

分类

read io thread

write io thread

insert buffer io thread

log io thread

Purge Thread

事务提交后undo log 不需要了，purge thread 负责回收undo 页

原来在master thread 的循环里面做，innodb 1.1 开始拆出了单独的purge thread

可用（innodb_purge_threads=1）控制线程数量

Page Cleaner Thread

1.2x中引入，之前在master thread 中完成脏页刷新，后来讲这个功能放到了单独的线程里面

Innodb 的内存

buffer pool

功能

解决磁盘和cpu之间的性能差异，innnodb 里面的读写都是基于缓冲池的，为了提高并发缓冲池有多个实例

数据类型

索引页

数据页

undo 页

insert buffer

adatptive hash index

lock info

data dictionary

缓冲池管理

buffer pool hit rate

正常应该大于95%，代表缓存命中率，如果小于这个值的话可能是发生了全表扫描

缓冲页链表分类

LRU List

innodb 的lru 实现

插入策略是新数据尾部插入，采用middle point insert strategy 插入

middle point insert strategy

类似jvm年轻待和老年待的思路，将lru list 用middle point 分为
new（老数据，在队列头部）和 old（新数据，在队列尾部）
然后多次访问统一个缓存页时就会判断缓存页存活是否超过InnoDB_old_blocks_time时间
超过则移入new 区

Free List

空闲可用的缓存页

Flush List

lru 中的脏页，需要用checkpoint 刷新到磁盘的页

重做日志缓冲（redo log buffer）

功能

缓存redo log，所占空间较小，默认8MB

redo log buffer的刷新时机

Master Thread的每秒循环

事务提交的时候

redo log buffer 剩余空间小于1/2

额外内存池（additional_mem_pool）

innodb 的内存管理和jvm是一致的，缓冲池类似堆的概念，‘额外内存池’则类似于jdb8里面的metaspace，主要负责存储innodb本身的一些数据结构

关键特性

Checkpoint

功能

刷新脏页到磁盘的操作，实现ACID中的Durability
，具体解决的问题的思路：每次刷新多少页到磁盘，每次从哪里取脏页，什么时候触发checkpoint

checkpoint的必要性

buffer pool 空间有限

redo log buffer 空间有限

什么是LSN（Log Sequence Number）

一个8字节的一直递增的整形数字，表示事务写入redo log 的字节总量，
每个页都有一个LSN 字段，redo log 中有LSN，checkpoint也有LSN

checklpoint类型

Sharp Checkpoint

数据库关闭时刷新所有脏页

Fuzy Checkpoint

数据库运行时刷新部分脏页

Fuzzy Check Point 的触发时机

Master Thread Checkpoint

FLUSH_LRU_LIST Checkpoint

LRU List中至少有n个页可用（innodb_Iru_scan_depth=100），该检查放在Page Cleaner Thread 中进行

Async/Sync Flush Checkpoint

重做日志文件不可用用时强制将一些页刷新会磁盘,保证redo log buffer 循环使用

checkpoint_age = redo_lsn - checkpoint_lsn
async_water_mark = 75% * total_redo_log_file_size
sync_water_mark = 90% * total_redo_log_file_size
checkpoint_age<async_water_mark => 不执行checkpoint

async_water_mark<checkpoint_age<sync_water_mark => async checkpoint

checkpoint_age>sync_water_mark => sync checkpoint

Dirty Page too Much Checkpoint

缓冲池脏页占比超过innodb_max_dirty_pages_pct，强制checkpoint 到磁盘，保证缓冲池有足够可用的页

插入缓冲

Insert Buffer

原理

innodb 按主键索引聚集，主键索引的操作是有序的，一般都是顺序io
，辅助索引（唯一性和非唯一性）叶子节点是主键值

非唯一性索引更新时的多次随机IO合并为1次，减少非唯一性索引的随机io次数，提高数据库写性能

使用条件

修改的非聚集索引不在缓冲池中

索引是辅助索引

辅助索引是非唯一的

因为唯一索引插入前要判断是否在树中已经重复了，这个查询操作本身就是随机IO无法避免，所以唯一非聚集索引没有使用Insert Buffer的必要

Change Buffer

说明

功能和Insert Buffer基本一致，应用于非唯一性聚集索引的修改优化
，在Insert Buffer的基础上做了细分：Insert、Delete、Purge Buffer
可以通过innodb_change_buffering（inserts、deletes、purges、changes、all、none）来控制启用那些类型的buffer 选项默认为all

Double Write

partitial write的问题定义

innodb的page size是16KB,操作系统的block size一般为4kb，磁盘io可能更小，所以innodb的一次脏页刷新到磁盘不能保证原子性，需要有一个机制来保证这个操作中断时磁盘上不会出现partitial write的问题

innodb 使用double write 来解决partitial write的问题，在对缓冲池的脏页进行flush时，并不直接写磁盘，而是会通过memcpy函数将脏页先复制到内存中的doublewrite buffer，之后通过doublewrite buffer再分两次，每次IMB顺序地写入共享表空间的物理磁盘上，然后马上调用fsync函数，同步磁盘，避免缓冲写带来的问题。在这个过程中，因为doublewrite页是连续的，因此这个过程是顺序写的，开销并不是很大。

可以通过skip_innodb_doublewrite禁用double write 功能

衍生问题：为什么Kafka InfluxDB Redis aof 不需要解决partitial write 的问题？
答案：Mysql 是in-place update 上面的这几个都是append only,不会更新原值

自适应哈希索引（AHI）

对于固定模式的等值类查询的优化，辅助索引的查询效率B+树高度的影响，一般高度为3-4的样子，所以一次完成辅助索引搜索需要3-4次查询，AHI就是将多次查询用hashmap的方式优化到一次，但是只对等值类查询生效，DBA不需要关注AHI的，他属于引擎的自优化项

要求

该模式访问了1000次

页通过该模式访问了N（页中记录/16）次

异步IO

同时提交多次IO后等待IO结果，async可以做io request merge ，相比同步IO（提交单个IO等待结果）性能提升明显

innodb 1.1.x之前aio 通过innodb存储引擎代码模拟实现，之后的版本是内核级别的async io实现称为Native AIO

刷新邻接页（Flush Neighbor Page）

刷新脏页的时候检查该页所在的区是否存在脏页，如果存在那么一起刷新