MySQL 8.3 Release Notes
要调查数据库页损坏，可以使用SELECT ... INTO OUTFILE从数据库中转储表。通常，以这种方式获得的大多数数据都是完整的。严重的损坏可能会导致SELECT * FROM 语句或tbl_nameInnoDB后台操作意外退出或断言，或者甚至导致InnoDB回滚恢复崩溃。在这种情况下，可以使用innodb_force_recovery选项强制InnoDB存储引擎启动，同时防止后台操作运行，以便您可以转储表。例如，可以在服务器选项文件的[mysqld]部分添加以下行，然后重新启动服务器：
[mysqld]
innodb_force_recovery = 1有关使用选项文件的信息，请参阅第6.2.2.2节，“使用选项文件”。
Warning
仅在紧急情况下将innodb_force_recovery设置为大于0的值，以便启动InnoDB并转储表。在这样做之前，请确保您有数据库的备份副本，以防止需要重新创建数据库。值为4或更高可能会永久损坏数据文件。仅在生产服务器实例上测试innodb_force_recovery设置为4或更高后，才使用该设置。
强制InnoDB恢复时，始终从innodb_force_recovery=1开始，并且仅在必要时逐渐增加该值。
如果您能够使用innodb_force_recovery值为3或更低的值来转储表，那么您相对安全地认为只有某些损坏的单个页面上的数据丢失了。值为4或更高被认为危险，因为数据文件可能会永久损坏。值为6被认为是激进的，因为数据库页面将被留在过时的状态中，从而可能引入更多的损坏到B树和其他数据库结构中。
作为安全措施，InnoDB禁止INSERT、UPDATE或DELETE操作，当innodb_force_recovery大于0时。值为4或更高的innodb_force_recovery设置将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_recovery值为3或更少，您可以DROP或CREATE表。DROP TABLE也支持使用innodb_force_recovery值大于3。DROP TABLE不允许使用innodb_force_recovery值大于4。
如果您知道某个表导致了意外退出回滚，您可以删除它。如果您遇到由于大量导入或ALTER TABLE导致的runaway回滚，您可以杀死mysqld进程，并将innodb_force_recovery设置为3，以便在不回滚的情况下启动数据库，然后DROP导致runaway回滚的表。
如果表数据中的损坏阻止您转储整个表内容，使用ORDER BY 子句的查询可能能够转储表的部分内容。primary_key DESC
如果需要高innodb_force_recovery值来启动InnoDB，可能存在损坏的数据结构，这可能会导致复杂查询（包含WHERE、ORDER BY或其他子句）失败。在这种情况下，您可能只能运行基本的SELECT * FROM t查询。