innodb_fast_shutdown的内幕

参数innodb_fast_shutdown提醒了我一直没研究过的innodb特性之一——insert buffer。首先简述这个参数，然后谈谈insert buffer的实现。

Innodb_fast_shutdown告诉innodb在它关闭的时候该做什么工作。有三个值可以选择：
1. 0表示在innodb关闭的时候，需要purge all, merge insert buffer,flush dirty pages。这是最慢的一种关闭方式，但是restart的时候也是最快的。后面将介绍purge all,merge insertbuffer,flush dirty pages这三者的含义。
2. 1表示在innodb关闭的时候，它不需要purge all，merge insert buffer，只需要flushdirty page。
3. 2表示在innodb关闭的时候，它不需要purge all，merge insert buffer，也不进行flushdirty page，只将log buffer里面的日志flush到log files。因此等下进行恢复的时候它是最耗时的。


那么在mysql restart的时候它的恢复流程（也称作crash recovery）是怎么样的呢？
1. 如果在上次关闭innodb的时候是在innodb_fast_shutdown=2或是mysql crash这种情况，那么它会利用redo log重做那些已经提交了的事务。
2. 接下来的操作就是这么几个：
a> Rollback uncompleted transitions 取消那些没有提交的事务
b> Purge all 清除无用的undo页
c> Merge insert buffer 合并插入缓冲


下面详解purge all、merge insert buffer、flush dirty page
1. Purge all 这个操作主要是删除那些无用的undo页。对于delete操作，innodb是通过先将要删除的那一行标记为删除，而不是马上清除这一行，因为innodb实现了MVCC，这些undo段用来实现MVCC机制。MVCC也就是常说的多版本控制，锁不阻塞读，读也不阻塞写，这样大大提高了并发性。那么在一致性读的时候，怎么才能找到和事务开始的那个版本呢？对于主键索引，每个行都有一个事务ID和一个undo ID，这个undo ID指向了这行的先前版本的位置。对于非主键索引，也就是常说的secondary index，是通过先找主键索引再找到undo段。而对于update操作，则是先标记删除，然后insert一个新的行，接下来如果有一致性读，那么查找old version的行的原理和delete操作是一样的，详情见[1]。现在接着说purge all操作，随着DML的操作越来越多，那么回滚段必然也会越来越多导致占用了许多磁盘空间，那么innodb就会定期删除一些无用的undo页，首先，innodb重启的时候必然undo页都会无效所以会进行purge all操作，另外，随着时间的推移必然一些事务已经完成，它们已不再需要某些undo页，那么这些undo在mysqld running的时候也会定期的进行清除，主要是在master thread中进行，虽然mysql5.5里面增加了一个参数innodb_purge_threads来进行purge工作，但是这个参数的默认值是0，手册上解释说这个功能在mysql5.5中还不完善，增加它的目的只是表明这是innodb的发展方向。
2. Merge insert bufferInsert buffer是innodb的一个特性之一，在非聚簇、且不是唯一索引（即非主键索引、非唯一索引）的情况下，如果插入的索引行所属的页在buffer pool中就直接更新这个页，否则它会将这个索引行插入到insert buffer中，然后定期对这个insert buffer进行合并（合并的本质工作就是将insert buffer中的信息更新到真正的索引文件中去）。因为innodb的secondary index是非聚簇的，那么插入很有可能带来大量的随机I/O，而如果利用insert buffer对一些属于相同页的行进行合并，那么就会减少随机IO从而提高性能。但是这里需要注意的是，insert buffer和doublewrite buffer是类似的概念，他实际上属于system tablespace中的一部分[2]，正由于它也是持久化存储，那么在服务器宕机或是重启之后这些信息不会丢失，所以也就有了在前面介绍innodb_fast_shutdown时所说：在innodb重启时，可能需要进行merge insert buffer。那么在什么情况下需要对insert buffer进行merge操作呢？
a> 在innodb restart的时候
b> master thread会定期的进行merge操作
c> 每次读取secondary index page时，如果所需页不在buffer pool，而这些页在insertbuffer中的时候，这时需要先对insert buffer进行合并，然后才能被读取。为什么这样呢？因为所有插入的索引行所属的页如果不在buffer pool中，而又在insert buffer中，那么它一定代表了页的最新状态（不理解？因为每次插入索引行的时候，如果所需页不在
buffer pool中就直接插入到insert buffer中，而一旦insert buffer merge后相关的行也就不在insert buffer更新secondary index page了）。这时或许你会问那么为什么不直接读取insertbuffer中的页然后继续操作而一定要合并（更新到索引文件）呢？因为在innodb中是数据文件（也就是主键索引）和索引文件缓存的，在insert buffer中读取了需要的页后，那么必然就会在buffer pool中缓存了这个页，而如果这个页还留在insert buffer中却不更新到secondary indexpage去，那么，第一，这将不能保证索引文件得到更新；第二，insert buffer的空间会被占用。而如果这一步将insert buffer 合并后，不但减小了insert buffer的使用空间，而且将这merge操作完成了一部分，减小了以后merge的负担（不是有句话叫做今日事今日毕么），不过这也减慢了读的操作，因为读操作必须等待这个页的合并。
3. Flush dirty page
这是最好理解的一个概念了，刷新脏页到磁盘。Innodb是数据文件和索引文件缓存的（innodb中的数据文件本质上也是索引文件，只是习惯这么称呼而已），从磁盘读到buffer中的文件被修改后，那么就成了dirty page脏页。而如果这些修改页的操作被提交了之后这些页就必须被flush到磁盘上。

啰嗦了这么久基本上将mysql的insert buffer工作原理大致说清楚了，不过需要注意的是在mysql5.5中这个insert buffer已经改名了，叫做change buffer，不见包含了insert buffer，而且包括了update buffer，delete buffer。最后提一句，随着SSD、Fusion IO这类型存储出现，很多时候我们考虑随机IO带来的影响或许对它们就不适用了。

因为没有读源码，这些理解是通过读其他的资料而来的，所以还留下了几个问题：
1. 实现insert buffer的数据结构是什么？我想应该是树状结构，因为这会为合并那一步提升效率。理由：第一，如果是无序链表的最开始的插入效率可能会比较高，但是最终判断哪些行在相同页或是相邻页的时候需要排序，这里的代价会比较高。而有序的链表在性能上没有二叉树这种结构效率高。
2. Insert buffer占多大空间？如果很小那岂不是只能容纳几行？那么在系统压力的时候，有空间来应付插入压力么？而如果比较大的，那么怎么保证在合并时候的效率？


参考文档：
[1] http://blogs.innodb.com/wp/2010/09/mysql-5-5-innodb-change-buffering/
[2] http://www.mysqlperformanceblog.com/2009/01/13/some-little-known-facts-about-innodb-insert-buffer/
[3]http://dev.mysql.com/doc/refman/5.0/en/innodb-insert-buffering.html