InnoDB内存区域的各个缓冲区
redo log:主要节省的是随机写磁盘的IO消耗（转成顺序写）
change buffer:主要节省是随机读磁盘的IO消耗。
changebuffer的作用？
答：InnoDb的页和操作系统的页大小不一致，InnoDB页大小一般为16K，操作系统的页为4K，InnoDB的页写入到磁盘的时，一个页需要分四次写。
如果存储引擎正在写入页的数据到磁盘时发生了宕机，可能出现页只写一部分的情况，比如只写了4K，就宕机了，这种情况叫做部分写失效（partial page write）,可能会导致数据丢失。因为写入一半，这个页已经损坏了，所以无法使用redo log进行恢复。所以提出了double write技术，其跟redo log一样，double write由两部分组成，一部分是内存中的double write，一个部分是磁盘上的double write。因为double write是顺序写入的，不会带来很大的开销。
Change buffer:
在MySQL5.5之前，叫插入缓冲(insert buffer)，只针对insert做了优化，现在对delete和update也有效，叫做写缓冲(change buffer)。
它是一种应用在非唯一普通索引页(non-unique secondary index page)不在缓冲池中，对页进行了写操作，并不会立刻将磁盘页加载到缓冲池，而仅仅记录缓冲变更(buffer changes)，等未来数据被读取时，再将数据合并(merge)恢复到缓冲池中的技术。写缓冲的目的是降低写操作的磁盘IO，提升数据库性能。 change buffer记录到数据页的操作：在访问这个数据页的时候，或者通过后台线程，或者数据shut down、redo log写满时触发。如果数据库大部分索引都是非唯一性索引，并且业务是写多读少，不会在写数据后立即读取，就可以使用Change buffer（写缓存）。
Change buffer占Buffer pool的比例，默认25%。
Binlog
Binlog以时间的形式记录了所有的DDL和DML语句（因为它记录的是操作而不是数据值，属于逻辑日志），可以用来做主从复制和数据恢复。
跟redo log不一样，它的文件内容是可以追加的，没有固定大小操作，在开启了binlog功能的情况下，我们可以把binlog导出成SQL语句，把所有的操作重放一遍，来实现数据的恢复。
Redo log(重做日志)：因为刷脏不是实时的，缓存中的脏数据，数据库宕机或者重启，这些数据就会丢失。所以数据内存必须有一个持久化的措施。InnoDB把所有对页面的修改操作写入一个日志文件。如果有未同步到磁盘的数据，数据库在启动的时候，会从日志文件进行恢复操作。事务ACID中的持久性就是用Redolog来实现。
同样存储到磁盘，为何存储到日志里边，而不存储到dbfilie里边，因为记录日志是顺序IO，刷盘是随机IO，本质是集中存储和分散存储的区别，因此先把修改写入日志文件，在保证内存安全性的情况下，可以延迟刷盘时间，进而提升系统吞吐。
崩溃恢复的时候，如何判断事务是否需要提交?
1、binlog无记录，redolog无记录：在redolog写之前crash，恢复操作：回滚事务
2、Binlog无记录，redolog状态prepare:在binlog写完之前的crash,恢复操作：回滚事务
3、Binlog有记录，redolog状态prepare:在binlog写完提交事务之前的crash:t提交事务
4、Binlog有记录，redolog状态commit:正常完成的事务，不需要恢复
三、一条SQL更新语句是如何执行的？
更新过程：将数据读到内存的缓冲池 buffer pool中，当然InnoDB的数据数据页并不是都是在访问的时候才缓存到buffer pool,通过预读机制，也就是说，设计者认为访问某个page的数据的时候，相邻的一些page可能会很快被访问到，所以先把这些page放到buffer pool中缓存起来；当然预读取也会带来一些副作用，就是导致占用的内存空间更多，剩余的空闲页更少。如果buffer pool size不是很大，而预读取的数据很多，那么很有可能真正需要缓存的热点数据被预读取数据挤出buffer pool淘汰掉了，下次访问的时候又要先去磁盘。为了解决这个问题，使用LRU缓存，map+双向链表的数据结构，
（1）先存储到缓存log buffer中，默认情况下会事务提交成功，数据会自动同步到磁盘，
（2）记录redo log，并将这行记录状态设置为prepare，
（3）写入binlog,并且提交事务，
（4）将redo log里这个事务的相关状态标记为commit；两阶段提交能够保证数据的一致性。
四、解释一下什么是索引？
数据库索引，是数据库管理系统（DBMS）中一个排序的数据结构，以协助快速查询，更新数据库表中的数据。类似一本书的目录。
InnoDB中索引的类型：
普通索引(Normal)：最普通的索引，没有任何的限制
唯一索引(Unique)：唯一所以要求键值不能重复。另外需要注意的是，主键索引是一种特殊的唯一索引，它还多了一个限制条件，要求键值不能为空。主键索引引用primay key创建。
全文索引(Fulltext):针对比较大的数据，比如我们存放的是消息内容，一篇几KB的数据的这种情况
五、B树与B+树的区别 (没有整理好，需要继续整理)
1、B树的路数比节点数多1，B+树的路数与节点数相同
2、B树中每个节点存储的是数据+键值+引用指针，B+ Tree的根节点和枝节点都不会存储数据，只有叶子节点存储数据。因为每个节点的页是16K，不存储data之后，可以存储更多的key值，从而减少IO次数。
3、•B+树的叶子结点都是相链的，因此对整棵树的便利只需要一次线性遍历叶子结点即可。而且由于数据顺序排列并且相连，所以便于区间查找和搜索。而B树则需要进行每一层的递归遍历。相邻的元素可能在内存中不相邻，所以缓存命中性没有B+树好。
4、B树也有优点，其优点在于，由于B树的每一个节点都包含key和value，因此经常访问的元素可能离根节点更近，因此访问也更迅速。
备注信息：InnoDB存储引擎中有页（page）的概念，页是其磁盘管理的最小单位，在InnoDB存储引擎中默认每个页的大小为16K，B+树将每个节点的大小设置和页大小一样，都为16K，因此读取一个节点，只需要一次IO。
而B树中每个节点中不仅包含数据的key值，还会包含除了key值外的所有data值。而每一页的存储空间是有限的，如果data数据较大时将会导致每个节点（即一个页）能存储的key的数量很小，当存储的数据量很大时同样会导致B-Tree的深度很大，增大查询时的磁盘IO次数，进而影响查询效率。而B+树中，所有数据节点都是按照键值大小顺序存放在同一层的叶子节点上，而非叶子节点上只存储key值信息， 这样可以大大加大每个节点存储的key值数量， 降低B+树的高度，减少查询时的IO次数。
做一个推理：InnoDb表的存储引擎中一页的大小为16k，一般表的主键类型占用8个字节，指针占用8个字节，那么一页可以存放16kb/(8b*8b)=1000个键值（关键字），所以一个高度为3的B+树可以存储1000^3即10亿条记录。查询时只需要两次IO操作就可找到要查找的记录。大大节约了查询时间。