Innodb 详解

线程：
Master Thread ：脏页刷新，合并insert buffer，回收undo页
IO Thread：aio(async io), 处理aio请求（如用户线程请求读取，获取future，read thread 实际读取，修改future，用户线程通过future获得结果）,分别有insert buffer thread(1)，log thread(1)，read thread(4)，write thread(4)
purge thread：回收undo页（事务提交后，undo页不需要了），减轻Master Thread 压力
page cleaner thread:脏页刷新，减轻Master Thread 压力

内存：
1 缓冲池：innodb_buffer_pool (数据，索引，undo，insert buffer, adaptive hash index…),可有多个
通过lru列表管理：
考虑普通lru：一边进，一边出，中间的地方被访问就放到入口
innodb lru: 进口在midpoint处（3/8的位置靠出口处），为什么这么做？避免全表扫的时候所有数据都被刷出，如果这样的话，只有后面3/8的数据会被刷出，前面数据不变的。
所以前面5/8称为new列表（显然热点数据），后面3/8称为old列表，page_made_young(页由old加入new，页必须等待一定时间才能加入，innodb_old_blocks_time)，page_not_made_young(页未能old加入new)
Lru列表是不断扩展的，（首先是空的，不断向Free 列表要内存，要不到了就淘汰尾端页）
页可压缩（16kb压为1，2，4，8），压缩页由unzip_lru列表管理
脏页同时存于lru列表和flush列表内，checkpoint机制刷回磁盘

2 重做日志缓冲 redo log buffer
master thread 每秒刷新到重做日志文件
事务提交时刷新（innodb_flush_log_at_trx_commit,0不刷新， 1同步写入磁盘，2异步写入操作系统缓存，为保证acid，必须设为1）
缓冲剩余空间小于一半时刷新

3 额外内存池（对某些数据结构本身的内存分配时从这里申请）

checkpoint：
write ahead (先保证redo落地，再谈数据落地)
lsn（log sequence number）:记录日志位置（字节偏移），存在于page，checkpoint和redo log中。
redo log（redo log entry: type/space(表空间)/page_no/body）:记录每个page的修改情况，同时lsn又移动了一个entry大小 （一般一组两个，ib_logfile0,ib_logfile_1 循环重用写入，先0，后1，再删除部分0并写入0）
log block（512byte,header,body(存放内容，即redo log entry),tailer，很明显一个block可能多个entry，或者一个entry占用多个block）
redo log file 第一个文件前2k（header，checkpoint1,空，checkpoint2）,第二个文件前2k为空，其余都存储log block
redo log基本顺序写(除了append log block外，还需更新前2k，所以说基本顺序写)，数据库运行不会读取，只在innodb启动时（不管上次是否正常关闭），进行恢复操作（物理日志恢复很快）
幂等 对未损坏页进行redo可以反复进行，损坏先修复再redo（doublewrite）

数据刷盘（checkpoint）
sharp:数据库关闭时所有脏页刷盘
fuzzy：特定时刻刷一部分脏页
master thread: 一定频率一定比例脏页刷盘
flush_lru_list: lru_list可用空间不够(不够100页)，干掉尾端页，若其中有脏页，刷盘。
async/sync flush: redo log file 不可用，redo_lsn-checkpoint_lsn太大（大于async点，甚至大于sync点）
dirty page too much:
注意事务提交的时候并不数据刷盘

Log sequence number 2225502463
Log flushed up to 2225502463
Pages flushed up to 2225502463
Last checkpoint at 2225502463

Log sequence number：修改内存page（新lsn）并同时生成log entry（新lsn，放于log buffer）
Log flushed up to：日志刷盘（每秒，事务， 一半）
Pages flushed up to：数据刷盘（checkpoint触发，sharp/fuzzy）
Last checkpoint at: 数据刷盘(一次checkpoint是需要时间的，结束后才会修改这个值)

内存中日志和数据变化是同时产生，但日志刷盘和数据刷盘是在两个机制下，数据库尽量控制日志刷盘lsn>数据刷盘lsn

数据恢复：checkpoint前已写入磁盘，不需要恢复，checkpoint后未提交事务不需要恢复
对于checkpoint后提交的事务（这时page可能已经flush但是last checkpoint没跟上，或者page未flush），比较磁盘page内lsn和redo log的lsn决定是否redo

master thread: 不处理用户活动，但是经常判断是否有用户活动决定是否background和是否flush并suspend
main loop
每秒（redo 刷新，脏页刷新，可能merge insert buffer，无用户活动，goto background loop）
每十秒（redo, 脏页，delete undo，merge insert buffer）
background loop :无用户活动或数据库关闭
（delete undo， merge insert buffer，无用户活动，goto flush loop，有用户活动，回 main loop）
flush loop 反复刷100脏页直到脏页比例低于一定比例，然后goto suspend loop
suspend loop 挂起线程等待事件

insert buffer:
主键索引插入一般很有序（自增），所以插入方便
secondary index ，not unique( 如果唯一的话还需要查找索引页判断是否违反这个约束)
实现：若 secondary index page在缓冲池内，插入，否则加入 insert buffer B+ tree，等一定时机merge到secondary index page内，通常多个insert合并到一个page内
change buffer: 扩展到delete和update(delete+insert)上，delete-marking(delete buffer) physical delete (purge buffer)
B+ tree 实现：所有表的 secondary index的都放在一起，node :（space（哪张表），page_no，索引记录）
insert buffer bitmap 记录所有secondary index page （每个4bit）可用空间和是否有数据在insert buffer中，确保insert能成功
merge 的时机：
1 secondary index page读到缓冲池，若查询bitmap此页有数据在insert buffer中，merge
2 插入时查询bitmap 发现secondary index page快没空间了，强行读取到缓冲池并merge
3 master thread

double write：
partial page write：flush list 单个page（16k）刷新到磁盘，操作非原子，page写了一半，宕机页损坏，无法通过redo log恢复（如redo告诉你所有数据+1，有一部分加1，一部分没加，你不知道从哪里开始）

skip_innodb_doublewrite 可关闭

adaptive hash index
O(1),快，自动对热点页建立hash index
热点：连续以某种访问模式访问了N次且以这种访问模式访问了这页M次
访问模式：等值查询，（a，b）a=xx, a=xx and b=xx 两种模式，交替这两种模式无效
将页内数据放入hash，如通过indexCol找到主键需几层B+查找，现在放入hash更快

aio
1 用户可连续发出多个操作，而不用等操作结束再下一个（比如java 拿到future1，再操作拿future2，统一等待future1,future2结果）
2 数据库底层可进行IO合并，如将多个相邻page的读取合并
以前代码模拟，现在一般操作系统支持，native aio

刷新邻接页
刷新脏页时脏页所在区（extent）的脏页一起刷新，aio将多个页刷新操作合并为一个io操作