要調查數據庫頁面損壞，您可以使用從數據庫轉儲表 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恢復