如果你拥有一个很大的内存，那么在享受性能的同时，你也享受着CRASH时，恢复时漫长等待的痛苦。
这个情况在MYSQL 5.5，InnoDB Plugin 1.0.7以后将有所改变

首先来了解一个崩溃恢复的原理 ：

崩溃恢复（Crash recovery）可以看成两个阶段，
第一阶段称为扫描重做日志（Redo scan），这时InnoDB读取磁盘上的Redo Log，并将其存放到一个Hash表中；
第二阶段应用这些Redo Log，将这些日志应用到Data Page上。

在将Redo Log读取到Buffer Pool的Hash表的过程中，InnoDB在需要的时候分配16K的Block用来存储这个这些Redo。
为了确保Buffer Pool中有足够剩余空间来存储数据页（Data Page），这样如果Redo很大的话，这个Block heap也会很大。
这里InnoDB每次读取一个Redo的时候，都会遍历一次前面的Heap来确保，没有占用太多的空间。
所以，如果崩溃前InnoDB的Buffer Pool很大，Dirty Page很多，这个Heap可能很大，每次遍历就会大大降低恢复时的效率。

InnoDB通过给这个Heap增加一个header来存储这些信息，解决了上面的问题。

恢复过程中，另一个耗时的操作是发生在应用Redo的阶段。
每一个应用了Redo Log的Data Page都会被放到一个叫Flush_list的链表中等待Flush，
而这个链表中的Data Page是严格安装其LSN顺序排列的，
在InnoDB正常工作的时候，这总是没有问题的，因为Data Page的LSN值总是单调增加的。
但是在恢复阶段，InnoDB则需要不断的扫描这整个链表来确定一个Data Page的位置。

InnoDB在恢复阶段，通过一棵辅助的红黑树（Red-Black Tree）来存储这些Page，借此来避免单纯的扫描。
在恢复阶段结束后，这棵红黑树将被删除，Flush_list仍然保持原来的结构。

测试结果；

在InnoDB Blog中，给出了一个测试：
Plugin1.0.6花费7小时38分钟恢复的过程，
使用Plugin1.0.7则仅仅花了13分56秒，总共快了32倍，
其中扫描Redo阶段快了16倍，应用日志阶段快了35倍。
以下是原文：
configuration parameters:
–innodb-buffer-pool-size=18g
–innodb-log-file-size=2047m
–innodb-adaptive-flushing=0
–innodb-io-capacity=100

The latter two are used to throttle flushing in order to maximize the number of dirty pages.
It took only about 20 min of running a workload to arrive to the test dataset, including cache prewarming.
So at time of crash we had:
Modified db pages 1007907
Redo bytes: 3050455773
And the recovery times were:
Plugin 1.0.7 (also Plugin 1.1): 1m52s scan, 12m04s apply, total 13m56s
Plugin 1.0.6: 31m39s scan, 7h06m21s apply, total 7h48m
1.0.7 (and Plugin 1.1) is better 16.95x on scan, 35.33x on apply, 32.87x overall