参数innodb_force_recovery影响了整个InnoDB存储引擎的恢复状况。该值默认为0，表示当需要恢复时执行所有的恢复操作。当不能进行有效恢复时，如数据页发生了corruption，MySQL数据库可能会宕机，并把错误写入错误日志中。
但是，在某些情况下，我们可能并不需要执行完整的恢复操作，我们自己知道如何进行恢复。比如正在对一个表执行alter table操作，这时意外发生了，数据库重启时会对InnoDB表执行回滚操作。对于一个大表，这需要很长时间，甚至可能是几个小时。这时我们可以自行进行恢复，例如可以把表删除，从备份中重新将数据导入表中，这些操作的速度可能要远远快于回滚操作。
innodb_force_recovery还可以设置为6个非零值：1～6。大的数字包含了前面所有小数字的影响，具体情况如下。
- 1（SRV_FORCE_IGNORE_CORRUPT）：忽略检查到的corrupt页。
- 2（SRV_FORCE_NO_BACKGROUND）：阻止主线程的运行，如主线程需要执行full purge操作，会导致crash。
- 3（SRV_FORCE_NO_TRX_UNDO）：不执行事务回滚操作。
- 4（SRV_FORCE_NO_IBUF_MERGE）：不执行插入缓冲的合并操作。
- 5（SRV_FORCE_NO_UNDO_LOG_SCAN）：不查看撤销日志（Undo Log），InnoDB存储引擎会将未提交的事务视为已提交。
- 6（SRV_FORCE_NO_LOG_REDO）：不执行前滚的操作。
需要注意的是，当设置参数innodb_force_recovery大于0后，可以对表进行select、create、drop操作，但insert、update或者delete这类操作是不允许的。
模拟故障
我们来做个实验，模拟故障的发生。在第一会话中，对一张接近1 000W行的InnoDB存储引擎表执行更新操作，但是完成后不要马上提交：
start transaction;
update Profile set password='';
--start transaction语句开启了事务，同时防止了自动提交的发生，update操作则会产生大量的回滚日志。这时，我们人为地kill掉MySQL数据库服务器。
ps-ef|grep mysqld
kill-9 pid
通过kill命令，我们人为地模拟了一次数据库宕机故障，当MySQL数据库下次启动时会对update的这个事务执行回滚操作，而这些信息都会记录在错误日志文件中，默认后缀名为err。如果查看错误日志文件，可得到如下结果：
090922 13：40：20 InnoDB：Started；log sequence number 6 2530474615 InnoDB：Starting in background the rollback of uncommitted transactions 090922 13：40：20 InnoDB：Rolling back trx with id 0 5281035，8867280 rows to undo InnoDB：Progress in percents：1090922 13：40：20 090922 13：40：20[Note]/usr/local/mysql/bin/mysqld：ready for connections. Version：'5.0.45-log'socket：'/tmp/mysql.sock'port：3306 MySQL Community Server（GPL） 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 InnoDB：Rolling back of trx id 0 5281035 completed 090922 13：49：21 InnoDB：Rollback of non-prepared transactions completed
可以看到，如果采用默认的策略，即把innodb_force_recovery设为0，InnoDB会在每次启动后对发生问题的表执行恢复操作，通过错误日志文件，可知这次回滚操作需要回滚8 867 280行记录，总共耗时约9分多钟。
我们做再做一次同样的测试，只不过在启动MySQL数据库前将参数innodb_force_recovery设为3，然后观察InnoDB存储引擎是否还会执行回滚操作，查看错误日志文件，可看到：
090922 14：26：23 InnoDB：Started；log sequence number 7 2253251193 InnoDB：！innodb_force_recovery is set to 3！ 090922 14：26：23[Note]/usr/local/mysql/bin/mysqld：ready for connections. Version：'5.0.45-log'socket：'/tmp/mysql.sock'port：3306 MySQL Community Server（GPL）
这里出现了“！”，InnoDB警告你已经将innodb_force_recovery设置为3，不会进行undo的回滚操作了。因此数据库很快启动完成，但是你应该很小心当前数据库的状态，并仔细确认是否不需要回滚操作。