强制(Forcing)恢复
如果出现数据库页面损坏，可以通过 SELECT INTO OUTFILE 从数据库中转储出表数
据,通常大部分的数据并未受损坏。 但是这些损坏可能引起 SELECT * FROM table
或 InnoDB 后台操作崩溃或中断(assert)，甚至是 InnoDB 的前滚(roll-forward)
恢复崩溃。从 InnoDB version 3.23.44 开始，在 my.cnf 中有个设置选项可以强
制 InnoDB 启动，以及防止后台操作的运行，因而你可以转储数据。例如，你可以
my.cnf 在中加入如下设置：
set-variable = innodb_force_recovery = 4
innodb_force_recovery 代替选择将在下面列出。 这个参数不能用于数据库的其它
方面！当设置值大于 0 时，作为安全尺度，InnoDB 禁止用户使用 INSERT, UPDATE,
或 DELETE 。
从 3.23.53 和 4.0.4 开始，即使强制恢复被使用你也可以使用 DROP 或 CREATE
一个表。 如果你确定表如引起回滚崩溃，你可以移除(drop)它。你也可以通过这个
停止一个因导入大量数据或 ALTER TABLE 而引起的失控(runaway)回滚。你可以杀死
mysqld 进程，并使用 my.cnf 设置项 innodb_force_recovery=3 不使用回滚。然
后就可以 DROP 那个引起失控(runaway)回滚的表。
下面较大的数意味着包含所有较低数所对就的安全防范。为了能够转储表设置至少为 4 ，
这是相对安全的，仅仅只有一些损坏的页面数据掉失。Option 6 is more dramatic,
because database pages are left in an obsolete state, which in turn may
introduce more corruption into B-trees and other database structures.
1 (SRV_FORCE_IGNORE_CORRUPT) 即使发现一个错误也启动服务；
试着使用 SELECT * FROM table 跳过损坏的索引记录和页面，这将帮助转储表。
2 (SRV_FORCE_NO_BACKGROUND) prevent the main thread from running:
如果在清理过程中将发生崩溃，这将预防它。
3 (SRV_FORCE_NO_TRX_UNDO) 恢复时不运行事务回滚。
4 (SRV_FORCE_NO_IBUF_MERGE) 防止插入缓冲区的归并操作：如果他们将引起崩溃，
最好不要操作他们；不要考虑表统计(table statistics)。
5 (SRV_FORCE_NO_UNDO_LOG_SCAN) 当启动数据库时不撤销日志(undo logs)：
InnoDB 将未完成的事务已提交。
6 (SRV_FORCE_NO_LOG_REDO) do not do the log roll-forward in connection with recovery.