要调查数据库页面损坏，您可以使用从数据库转储表 SELECT ... INTO OUTFILE。通常，以这种方式获得的大多数数据是完整的。严重损坏可能导致语句或 后台操作崩溃或断言，甚至导致前滚恢复崩溃。在这种情况下，您可以使用该 选项强制启动存储引擎，同时防止后台操作运行，以便您可以转储表。例如，您可以在重新启动服务器之前将以下行添加到选项文件的部分： SELECT * FROM tbl_nameInnoDBInnoDBinnodb_force_recoveryInnoDB[mysqld]
[mysqld]
innodb_force_recovery = 1警告
innodb_force_recovery 在紧急情况下 仅设置为大于0的值，以便您可以启动InnoDB和转储表。
在此之前，请确保您拥有数据库的备份副本，以备需要重新创建时使用。值为4或更大可能会永
久损坏数据文件。innodb_force_recovery在成功测试数据库的单独物理副本上的设置后，仅在
生产服务器实例上使用 4或更高的设置。强制InnoDB恢复时，您应该始终使用
innodb_force_recovery=1并且只在必要时以递增方式增加值。innodb_force_recovery默认为0（没有强制恢复的正常启动）。允许的非零值为 innodb_force_recovery1到6.较大的值包括较小值的功能。例如，值3包括值1和2的所有功能。
如果您能够以innodb_force_recovery3或更小的值转储表 ，那么您相对安全，只有损坏的单个页面上的某些数据会丢失。值为4或更高被认为是危险的，因为数据文件可能会永久损坏。值6被认为是极其严重的，因为数据库页面处于过时状态，这反过来可能会在B树 和其他数据库结构中引入更多损坏。
作为安全措施，InnoDB防止 INSERT， UPDATE或 DELETE操作时， innodb_force_recovery是大于0的较大innodb_force_recovery 的4米以上的地方设置InnoDB在只读模式。
1 （SRV_FORCE_IGNORE_CORRUPT）
即使检测到损坏的页面，也允许服务器运行 。尝试 跳过损坏的索引记录和页面，这有助于转储
表。 SELECT * FROM tbl_name
2 （SRV_FORCE_NO_BACKGROUND）
防止主线程和任何清除线程运行。如果在清除操作期间发生崩溃 ，则此恢复值会阻止它。
3 （SRV_FORCE_NO_TRX_UNDO）
崩溃恢复后 不运行事务 回滚。
4 （SRV_FORCE_NO_IBUF_MERGE）
阻止插入缓冲区合并操作。如果它们会导致崩溃，则不会这样做。不计算表 统计信息。此值可
能会永久损坏数据文件。使用此值后，请准备删除并重新创建所有二级索引。设置 InnoDB为只读。
5 （SRV_FORCE_NO_UNDO_LOG_SCAN）
启动数据库时 不查看撤消日志： InnoDB将未完成的事务视为已提交。此值可能会永久损坏数据
文件。设置InnoDB为只读。
6 （SRV_FORCE_NO_LOG_REDO）
不执行与恢复相关的重做日志前 滚。此值可能会永久损坏数据文件。使数据库页面处于过时状
态，这反过来可能会在B树和其他数据库结构中引入更多损坏。设置 InnoDB为只读。您可以SELECT从表中转储它们。使用innodb_force_recovery3或更小的 值，你可以DROP或 CREATE表。DROP TABLE也支持 innodb_force_recovery大于3 DROP TABLE的innodb_force_recovery值。大于4 的值不允许 。
如果您知道给定的表导致回滚崩溃，则可以删除它。如果您遇到由大量导入失败导致的失控回滚，或者ALTER TABLE您可以终止mysqld进程并设置 innodb_force_recovery为 3在没有回滚的情况下启动数据库，然后DROP启动导致失控回滚的表。
如果表数据中的损坏阻止您转储整个表内容，则带有子句的查询可能能够在损坏的部分之后转储表的一部分。 ORDER BY primary_key DESC
如果一个高innodb_force_recovery 值是必需的开始InnoDB，有可能是，可能导致（含有查询的复杂查询损坏的数据结构WHERE，ORDER BY或其它条款）失败。在这种情况下，您可能只能运行基本SELECT * FROM t 查询。
参考文档：强制InnoDB恢复
原文地址：http://blog.51cto.com/linux10000/2177265