如果你拥有一个很大的内存，那么在享受性能的同时，你也享受着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