InnoDB概念
MySQL是当前最流行的关系型数据库。MySQL的体系架构如下图所示：
MySQL架构：
Connectors：MySQL向外提供的交互接口：
Java等语言可以通过该接口实现和SQL的交互，操作SQL语句。
Management Service & Utilities：管理服务组件和工具组件：
提供对MySQL的集成管理，包括：备份，恢复，安全管理等。
Connection Pool：连接池组件：
负责监听客户端到MySQL的请求，创建线程负责之间的通信。
SQL Interface：SQL接口组件：
接收客户端的SQL命令，将结果返回客户端。
Parser：查询分析器组件：
分析SQL的合法性，并解析SQL的数据结构。
Optimizer：优化器组件：
对SQL进行优化分析。
Caches & Buffers：缓存组件：
SQL结果等缓存。
Pluggable Storage Engine：插拔式存储引擎：
可插拔式的存储引擎，用于表的创建，数据检索，索引创建等；也可满足自定义的存储引擎开发。
File System：物理文件：
实际存储数据的文件。
Files & Logs：文件和日志：
存储各式各样的日志文件。
其中MySQL的关键特点就是可插拔的存储引擎；其中InnoDB是MySQL的默认存储引擎，也是应用最为广泛的存储存储引擎，本文主要介绍InnoDB存储引擎的关键特性以及这些特性的一些思考。
数据库和数据实例的区别：
- 数据库是文件的集合，是依照某种数据模型组织起来并存放于二级存储器中的数据集合；
- 数据库实例是程序，是位于用户与操作系统之间的一层数据管理软件；
InnoDB关键特性
InnoDB有以下关键特性，其中前三个是数据库最通用的特性：
- Change Buffer（写缓存）
- Double Write（二次写）
- Adaptive Hash Index（自适应哈希索引）
- Async IO（异步IO）
- Flush Neighbor Page（属性邻接页）
1. Change Buffer
Change Buffer是InnoDB中最特殊的一个特性。Change Buffer是从InnoDB 1.0.x版本之后的引入的概念，在1.0.x版本之前叫Insert Buffer（插入缓存）。Insert Buffer顾名思义是针对Insert的缓存。
1.1 问题诞生背景
对于InnoDB，所有的数据，索引等都是以文件的形式存储，以B+树的形式存储。
InnoDB的索引分为两种：聚簇索引（Primary Index）和非聚簇索引（Secondary Index）；其中聚簇索引的B+树叶子节点存放的是真实的数据；而非聚簇索引的叶子节点存放的是聚簇索引的主键值。
我们先从索引的角度来描述下问题的背景：
- 对于聚簇索引，主键是唯一的；当插入新的数据时，需要检查下磁盘是否有主键冲突，这步磁盘访问必不可少；此外，一般对于主键的插入是顺序的（比如id自增列），这样磁盘是顺序读写的，有较好的性能。
- 对于非聚簇索引，列值不唯一；当插入新的数据时，插入的数据很难是按递增的顺序插入的，这时候对于插入操作都是随机的；如果有大量的插入操作，则会有大量的随机IO，会严重影响磁盘的性能。
因此Insert Buffer诞生的问题背景是： 大量的非聚簇索引插入操作？？？
产生的问题背景也反映了Insert Buffer需要满足两点：
- 必须是非聚簇索引；
- 索引的数据不是唯一的；（后面也会有介绍）
1.2 内部实现
- MySQL数据存储包含内存和磁盘两部分；
- 内存缓冲池以页（Page）为单位，缓存最热的是：数据页和索引页；
- InnoDB以变种LRU（加了mid位置和时间的概念，非常类似于JVM的内存管理）的算法来管理缓冲池，解决了“预读失效”和“缓冲池污染”的问题；
（1）情况一
当要插入的数据已经在缓冲池了，则只需要插入redo日志文件一次磁盘操作；但redo的磁盘是顺序写，效率很高；因此这种情况不需要Insert Buffer。
缓冲池会定期的刷新到磁盘上，而不是每次都刷新，这样会降低磁盘的IO，提升性能，说白了就是批量写（可能会有同一个数据页的合并操作）。
（2）情况二
当要插入的数据不再缓冲池中，这时候需要怎么办？
为了避免大量的随机IO，提出了Insert Buffer的概念；当插入数据时，先把数据插入到Insert Buffer中；当需要回刷磁盘时，会把Insert Buffer中的数据进行merge后写入磁盘（因为有merge，为了表示现有页的空闲空间，还需要一个特殊的页来保存每个非聚簇索引页的空闲空间），降低了磁盘随机IO。Insert Buffer也是B+树的结构，插入数据时也是按照页来组织聚簇索引和非聚簇索引数据。
举个形象的例子来说明Insert Buffer的具体作用：
图书管理员进行书籍整理，有两种做法：
- 每归还一本书，就去对应的书架上归还这本书；
- 先把书放在柜台，等书达到一定量的时候，进行批量的放回对应的书架；
正常人都会选择第二种做法；而柜台就是Insert Buffer，归还的书会先在柜台上进行整理，合并，然后一起放回书架，减少了书架的随机访问。
在MySQL5.5之后，不仅针对insert操作，还针对update和delete操作，改名为Change Buffer,原理是一致的。
Change Buffer还有一个细节点，当Change Buffer中的有数据没有写到磁盘前，数据库宕机了，这个时候Change Buffer的数据就恢复不了了，因此鉴于这种情况，InnoDB会把Change Buffer中的数据定期通过merge操作刷回表空间中的索引文件。
Change Buffer结构图:
从图中可以看出，Change Buffer并不仅仅指的是内存中的一块，还包含了物理磁盘上的共享表空间。
1.3 缺点
- 如果有大量的DML变更操作，数据宕机后，会导致恢复的时间较长；
- 有大量插入的时候，会导致占用较多的Buffer Pool内存，会影响其他数据的空间；
- 对于不同的硬件配置和负载，Change Buffer无法进行控制，比如磁盘和SSD；
2. Double Write
从IO的角度来看，InnoDB是以页为维度来读取数据，正常InnoDB的页可以配置为4K，8K，16K;而文件系统的IO读写最小单位是4K，也有些是1K；磁盘的读写最小单位是扇区（512KB）。
由于各系统以及硬件IO读写的单位不一致，往往底层的单位要小于上层的单位，因此上层就会存在部分写的场景：当写一部分数据的时候，机器宕机了，这样就会导致部分写的场景。（磁盘是由硬件保证，要么512KB全部写成功，要么都失败，不存在部分写的场景）
2.1 问题诞生背景
由上述知道，InnoDB的IO最小单位是页,正常大小为16K（可以配置为4K，8K等）；当缓冲池中的脏页回写磁盘时，磁盘的页和缓冲池的页是对等的，也就是要回写16K的数据到磁盘；而文件系统的读写单位可能是4K；这样就需要写入4次，才能完整的把脏页刷回去；如果在写2次的时候，机器断电宕机了，这个时候磁盘的页就被污染了。
基于这种场景，InnoDB诞生了Double Write的特性，用于解决partial page write（部分写）的问题。
2.2 内部实现
参考Change Buffer的设计，Double Write也在Buffer Pool中开辟一块内存，用来存放修改的脏页；并在磁盘的共享表中间中存放脏页，Double Write的逻辑如下图所示：
Double Write的步骤：
- 当触发脏页刷新时，先把脏页拷贝到Double Write内存中；
- 接着把Double Write中的脏页顺序的写到共享表空间中，这部分是顺序写入磁盘，性能很高；
- 异步的将共享表空间的数据离散的写入到各个表空间中；
Double Write如何宕机恢复的？？？
- 如果写入Double Write Buffer时失败，这个时候页还没有刷新回磁盘，也就没有发生部分写的问题，因此直接从磁盘加载原始数据，并通过事务日志重新计算写入Double Write Buffer。
- 如果写入磁盘时，宕机，由于共享表空间中副本数据恢复，重新写入磁盘即可。
为啥不用redo log解决部分写的问题？？？
这个涉及到redo log的数据设计；如果redo log中保存了所有的数据和操作，那么redo log的size会非常大，不利于日志文件存储；因此InnoDB对于redo log的设计是保存页的指针之类的数据；因此redo log无法恢复物理页，因为redo log中不保存真实的数据。
2.3 缺点
虽然共享表空间的写入是磁盘顺序写，但依然会影响MySQL的性能；尤其是InnoDB为了保证写入共享表空间数据的完整性，在每次写入后都会调用fsync操作等待磁盘操作结束，硬盘的fsync性能比较慢；
3. Adaptive Hash Index
自适应哈希索引是InnoDB内部的一个优化特性，一般不需要开发人员关注。
3.1 问题诞生背景
首先了解下InnoDB的数据存储，InnoDB的数据和主键索引一起存储，主键索引的叶子节点存放的是数据；非主键索引叶子节点存放的是主键的key值。
当通过非聚簇索引来查询数据时，根据B+索引树查询叶子节点的主键key,然后根据主键key再去主键索引的B+树上找到对应的叶子节点的数据。
可以看出来通过非聚簇索引来查询数据时，需要访问两个B+树，而自适应哈希索引就是为了解决这个问题，直接构造非聚簇索引key到真实数据的哈希索引，哈希的时间复杂度是O（1）；因此减少了两次B+树的查询操作。
自适应哈希索引是索引的索引 ！！！
3.2 内部实现
自适应哈希索引的难点在于信息统计，要统计出查询的热点数据，为这些热点数据建立哈希索引。比如对于同一条件的频繁访问，可以构造出哈希索引，下次同样的条件可以直接获取结果。
自适应哈希索引的结构如下图所示：
自适应哈希索引实现的条件：
- 精确条件查询，以该条件查询超过100次；
- 页访问的次数N=页记录数/16；
(内部具体的信息统计涉及很多参数，后续分析)
3.3 缺点
- 自适应哈希索引也是占用Buffer Pool的空间，会影响其他类型数据的空间容量；
- 自适应哈希索引只支持精确条件查询，不支持范围查找；
- 自适应哈希索引只有在极端的情况下（大量固定条件的查询），才有意义，降低逻辑读时间；
4. Async IO
为了提供磁盘操作性能，现在的数据库系统都是采用异步IO的方式来处理磁盘操作。异步IO还支持批量操作，把多个页进行整合一起进行IO操作，如果是同一页的数据，或者连续的数据，会提高磁盘的IO性能。
5. Flush Neighbor Page
刷新邻接页是根据“局部性”原理，其工作原理是：
当刷新一个脏页时，InnoDB存储引擎会检测该页所在区（extent）的所有页，如果是脏页，那么一起进行刷新。这样做的好处显而易见，通过AIO可以将多个IO写入操作合并为一个IO操作，故该工作机制在传统机械磁盘下有着显著的优势。
InnoDB文件的格式是idb后缀，其中存放了表的数据，又称为表空间Tablespace，表空间又分为多个段Segment；一个Segment又分为多个区Extent；一个区又分为多个页Page；一个页包含了多个行Row。
后记
InnoDB的关键特性和文件的存储结果密切相关，后面会分析下InnoDB表数据的文件存储结构。
