MySQL 8.4 Release Notes
17.20.3 强制 InnoDB 恢复
为了调查数据库页面损坏，您可能需要从数据库中dump表格使用SELECT ... INTO OUTFILE。通常，通过这种方式获得的数据大多数是完整的。但是严重损坏可能会导致SELECT * FROM 语句或tbl_nameInnoDB 后台操作突然退出或断言，甚至导致InnoDB 回滚恢复崩溃。在这种情况下，您可以使用innodb_force_recovery 选项强制InnoDB 存储引擎启动，而防止后台操作运行，以便dump表格。例如，您可以在重启服务器前，在option文件的[mysqld]部分添加以下行：
[mysqld]
innodb_force_recovery = 1关于使用选项文件的信息，请见第6.2.2.2节，“使用选项文件”。
Warning
只有在紧急情况下，才将innodb_force_recovery设置为大于0的值，以便可以启动InnoDB并dump您的表。之前，确保您已经备份了数据库，以防需要重新创建它。值为4或更高的可能会永久损坏数据文件。在生产服务器实例上，只有在成功测试设置后，才使用innodb_force_recovery设置为4或更高的值。强制InnoDB恢复时，总是从innodb_force_recovery=1开始，然后逐步增加值，以便必要。
innodb_force_recovery的默认值为0（正常启动无强制恢复）。innodb_force_recovery的可允许非零值是1到6。较大的值包括较小值的功能，例如值为3包括值为1和2的所有功能。
如果您可以使用innodb_force_recovery值为3或更小，那么您相对安全地只损失某些单独页面的数据。值为4或更大被认为危险，因为数据文件可能永久损坏。值为6被认为是 drastic 的，因为数据库页面留在过时状态，可能引入B-trees和其他数据库结构的更多损坏。
出于安全考虑，InnoDB在innodb_force_recovery大于0时阻止INSERT、UPDATE或DELETE操作。设置innodb_force_recovery为4或更大将使InnoDB处于只读模式。
-
1(SRV_FORCE_IGNORE_CORRUPT)允许服务器继续运行，即使检测到损坏的页面。尝试使
SELECT * FROM跳过损坏的索引记录和页面，帮助dump表。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)在启动数据库时，不查看undo日志：
InnoDB将视所有不完整事务为已提交。这个值也可以永久损坏数据文件。设置InnoDB为只读。 -
6(SRV_FORCE_NO_LOG_REDO)不执行redo日志的回滚操作。这一值可能永久损坏数据文件，留下数据库页面处于过时状态，从而引入B树和其他数据库结构的更多损坏。将
InnoDB设置为只读。
您可以从表中SELECT它们以将其dump出来。使用innodb_force_recovery值为3或更小，您可以DROP或CREATE表。使用innodb_force_recovery值大于3的也支持DROP TABLE。使用innodb_force_recovery值大于4时不允许DROP TABLE。
如果您知道某个表导致了意外退出回滚，可以删除它。如果您遇到由大规模导入或ALTER TABLE引起的 runaway 回滚，可以杀死mysqld进程，然后将innodb_force_recovery设置为3，然后删除引起 runaway 回滚的表。
如果表数据中的损坏阻止您dump整个表内容，一条带有ORDER BY 子句的查询可能可以dump该表的部分内容。primary_key DESC
如果需要高innodb_force_recovery值来启动InnoDB，可能存在损坏的数据结构，这些结构可能会导致复杂查询（包含WHERE、ORDER BY或其他子句）失败。在这种情况下，您可能只能运行基本的SELECT * FROM t查询。