Innodb 架构

凭着记忆自己画了一下：

 

总体上看，主要由 内存 + 硬盘 中的内容构成

内存还可分为 innodb 自己的内存 和 操作系统文件系统的缓存

 

Adaptive hash index：自适应 散列 索引

　　　　自适应指的是 ：对于辅助索引，如果查询某二级索引的频率到达阈值，会将该二级索引上经常查询的前几列条件和记录所在磁盘块号建立对应关系

Buffer Pool 是Innodb 中内存部分，包括两个主要部分：

　　Dirty Page ： 脏数据页

　　redo log buffer ： redo log 写入 文件之前会先写入 redo log buffer

os File System cache：

　　写入文件，但是未被 fsync 或者 bdflush 进程 刷入到磁盘文件的 内容会 保存在文件缓存中

Double write buffer：

　　在 innodb 的页 和 操作系统的页 大小不一样的情况下（innodb 的页一般为 16kb，操作系统的页为 4kb），innodb 的页需要多次写入磁盘才能完整写完

　　即 innodb 页写入磁盘不是原子性的，如果写了一半就断电，那么原本的页就被破坏了。redolog 中有的只是增量修改，不一定能找回原先页的全部内容，而且redolog是循环写的，之前关于这个页的redolog记录可能已经被新的redolog 记录覆盖。

　　binlog 同理，如果这个页是binlog 诞生之初就存在的，有内容的，那么binlog无法找回这个页的完整内容。

　　所以，最后要先保证在 硬盘中先写一份完整的拷贝，再去写磁盘中真正的数据页，真正地去覆盖数据页。

　　如果数据页损坏，那么可以去磁盘中找完整拷贝，把拷贝写到目标数据页上。

Change Buffer：

　　对于写操作，如果不涉及唯一性的内容，比如聚簇索引和唯一索引，那么可以先将写操作缓存在内存的change buffer中。

　　等待要读数据页的时候，再把硬盘中的数据页读出来，和 change buffer 中的修改合并（merge）。

　　对于写操作频繁，读操作少的事务来说收益显著。比如写日志的不会轻易被读到的东西。

　　如果读操作频繁，那么不通过 change buffer，直接拿磁盘中数据页出来修改 会快得多，change buffer 还需要占用 buffer pool。

　　对于读频繁，几乎不改的业务，可以把change buffer 调小

　　change buffer 优化的目标是 辅助索引页，要知道，在 idb 存储中，数据页是独立的，不含主键，主键索引也是独立的数据页，辅助索引也有独立的数据页。

　　修改数据还是要读入数据页的，但是辅助索引页可以不读进来，通过change buffer 在读的时候再 merge 回去，所以 change buffer 的收益在于 辅助索引页读入的减少