innodb_fast_shutdown的内幕

Innodb_fast_shutdown告诉innodb在它关闭的时候该做什么工作。有三个值可以选择：
1.  0表示在innodb关闭的时候，需要purge all, merge insert buffer,flush dirty pages。这是最慢的一种关闭方式，但是restart的时候也是最快的。后面将介绍purge all,merge insert buffer,flush dirty pages这三者的含义。
2.  1表示在innodb关闭的时候，它不需要purge all，merge insert buffer，只需要flush dirty page。
3.  2表示在innodb关闭的时候，它不需要purge all，merge insert buffer，也不进行flush dirty 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 buffer Insert 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，而这些页在insert buffer中的时候，这时需要先对insert buffer进行合并，然后才能被读取。为什么这样呢？因为所有插入的索引行所属的页如果不在buffer pool中，而又在insert buffer中，那么它一定代表了页的最新状态（不理解？因为每次插入索引行的时候，如果所需页不在
buffer pool中就直接插入到insert buffer中，而一旦insert buffer merge后相关的行也就不在insert buffer更新secondary index page了）。这时或许你会问那么为什么不直接读取insert buffer中的页然后继续操作而一定要合并（更新到索引文件）呢？因为在innodb中是数据文件（也就是主键索引）和索引文件缓存的，在insert buffer中读取了需要的页后，那么必然就会在buffer pool中缓存了这个页，而如果这个页还留在insert buffer中却不更新到secondary index page去，那么，第一，这将不能保证索引文件得到更新；第二，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
---------------------