MySQL在启动的时候，会进行前滚（利用redo log实现）和回滚（利用undo log和bin log实现）事物，来保证与前一次数据库服务关闭前的数据版本的最终一致性。

Crash Recovery的过程，可查阅参考文档一。

我们知道，不同的落盘机制影响着redo、undo、binlog以及数据本身的刷新策略。

1、Redo log

innodb_log_buffer_size控制着redo log的缓冲池大小，线程：master therad、参数：innodb_flush_log_at_trx_commit、以及缓存池的剩余容量触发（1/2大小）同时控制着redo log落盘的频率

2、Undo log

每做一次记录的修改操作，都会伴随着undo log的产生，修改操作所在的事物提交后，如果undo log不再被其他事物引用，就会被purge掉（正常情况下，会定期删除那些标记为删除并且不再被MVCC或rollback需要的undo页）。

注：insert操作的undo可以在所在事物提交后立即删除。相反，update和delete则仍然需要在一段时间内保存undo

3、binlog

sync_binlog，innodb_flush_log_at_trx_commit 控制着事物提交是如何影响binlog落盘的。

而innodb_support_xa同时限制着redo log和binlog。

4、Data

BP中脏页的刷新，在关闭时，由innodb_fast_shutdown控制。

innodb_fast_shutdown决定了InnoDB在关闭时需要做那些事情，可选取值：0、1、2

0、对所有undo页进行purge（数据库重启意味着所有的undo页都变为无用的了），对change buffer进行merge，刷新BP中的脏页。称之为“slow shutdown”或者“clean shutdown”，可能会耗费几分钟，甚至几小时。在进行MySQL大版本升降级时，需要如此设置。

1、默认值。在=0的操作的基础上，跳过那些一定要flush的操作（certain flush operations）仅刷新脏页，称之为“fast shutdown”。

2、不刷新BP中的脏页到磁盘上，仅刷新redo log buffer之后就直接shutdown，就好似MySQL是crash掉的。（下次重启时将会耗时在crash recovery的过程中）。一般用于紧急情况下，需要尽快关机的情况。

由于模式0在数据库重启时，不需要做crash recovery，所以启动速度是最快的；而模式1需要做少量的crash recovery，速度适中；反观模式2，则要耗费大量的时间在这个过程上。

总结如下：

innodb_force_recovery决定了InnoDB在开启时需要做那些事情，可选取值：0~6

参考文档：

InnoDB recovery详细流程

InnoDB crash recovery speed in MySQL 5.6