InnoDB存储引擎表的损坏可能是多种因素导致的，比如服务器断电、系统崩溃、硬盘损坏、写数据过程中mysqld进程被kill掉。
严重的损坏可能导致无法执行SELECT语句或InnoDB引擎意外退出，甚至导致InnoDB向前滚动恢复崩溃。在这种情况下，我们可以使用innodb_force_recovery选项强制 InnoDB 存储引擎启动，同时阻止后台操作运行，以便使用SELECT ... INTO OUTFILE从数据库中转储表中数据，以这种方式获得的大部分数据都是完好无损的。
例如，将以下行添加到选项文件的 [mysqld] 部分，然后再重新启动服务器：
[mysqld]
innodb_force_recovery = 1
注意：
在强制 InnoDB 恢复时，应始终从 innodb_force_recovery=1 开始，并且仅在必要时增加值。在此之前，请确保做好数据库的备份副本，以便需要重建数据库。
innodb_force_recovery设置为 4 或以上可能会永久损坏数据文件，只有在数据库的物理副本测试设置成功后，才能在生产环境使用4或更大的值。
innodb_force_recovery的默认值是0（正常启动，不使用恢复模式），可配置的值为1~6，较大的值会包含较小的值的所有功能。举个例子，配置为3，那么会包含选项1、2的所有功能。
当innodb_force_recovery配置为 3 或更小的值可以转储表，数据相对安全，因为只有损坏的单页上的某些数据丢失。值为 4 或更高值会比较危险，因为数据文件可能会永久损坏。值为6时，因为数据页处于废弃状态，这可能会给 B 树和其他数据库结构带来更多的破坏。为了安全，innodb_force_recovery>0时禁止使用INSERT、DELETE、UPDATE操作。innodb_force_recovery>=4时InnoDB进入只读模式。
innodb_force_recovery选项：
1 (SRV_FORCE_IGNORE_CORRUPT)
检查到的错误页，仍允许服务运行。在转储表时会跳过损坏的索引和页。
2 (SRV_FORCE_NO_BACKGROUND)
阻止主线程和任何清理线程运行，执行清理操作时可能会引起crash。
3 (SRV_FORCE_NO_TRX_UNDO)
不执行事务回滚。
4 (SRV_FORCE_NO_IBUF_MERGE)
不执行 change buffer的合并操作。此值可能会永久损坏数据文件。使用此值后，将删除并重建所有二级索引且将 InnoDB 设置为只读。
5 (SRV_FORCE_NO_UNDO_LOG_SCAN)
启动数据库时不查看undo log，InnoDB将未提交的事务视为已提交。此值可能会永久损坏数据文件。
6 (SRV_FORCE_NO_LOG_REDO)
redo log不做前滚操作。
通过innodb_force_recovery启动后，可进行如下操作：
1.导出数据
select * into outfile '/tmp/outfile.txt' from tb1;
2.删除损坏的表
drop table tb1;
3.创建新表
create table `tb1` (id varchar(20));
4.导入数据
LOAD DATA local INFILE '/tmp/outfile.txt' IGNORE INTO TABLE tb1;
如果表数据损坏导致无法转储数据，可以尝试加上ORDER BY primary_key，这个操作可以跳过表中损坏的部分转储数据。如果数据结构已经损坏，可能无法使用复杂的查询语句，只能通过SELECT * FROM tb1来保存数据。
欢迎大家留言交流。
