對于InnoDB引擎來說，擁有自動恢復(fù)機制。在通常情況下，當服務(wù)器出現(xiàn)宕機時，InnoDB是可以在重啟時自動修復(fù)錯誤的。在某些情況下，因為出現(xiàn)的異常情況也會導(dǎo)致其無法進行修復(fù)。為此，可以通過設(shè)置“innidb_force_recovery”參數(shù)，來進行人工修復(fù)。該參數(shù)可以設(shè)置不同的值，對應(yīng)不同的修復(fù)級別。在默認情況下，該參數(shù)的值為0，表示不啟用。如果對其改變的話，數(shù)據(jù)表就會處于只讀狀態(tài)，而且只能執(zhí)行基本的Select等語句，不能附加Where，Order BY等參數(shù)。因為數(shù)據(jù)表處于恢復(fù)狀態(tài)，不能進行插入刪除等修改操作。如果將其設(shè)置為1，例如“innodb_force_recovery=1”表示即使發(fā)現(xiàn)了損壞，也會讓服務(wù)繼續(xù)運行，這對于數(shù)據(jù)的備份和轉(zhuǎn)存當前的數(shù)據(jù)很有用。

這適用于數(shù)據(jù)本身沒有大的損壞，在可以正常讀取數(shù)據(jù)的情況下，將數(shù)據(jù)備份出來，通過重新創(chuàng)建同樣的數(shù)據(jù)庫，并將數(shù)據(jù)恢復(fù)進來。該模式可以滿足一般情況下的數(shù)據(jù)恢復(fù)之用。如果將其設(shè)置為2，例如“innodb_force_recovery=2”，表示在主線程和任何清除線程運行時，可以防止因為清除操作導(dǎo)致服務(wù)器宕機的發(fā)生。根據(jù)以上分析，在InnoDB引擎運行時，會執(zhí)行各種循環(huán)，在其中會執(zhí)行清除操作，將緩存中的數(shù)據(jù)寫入磁盤，同時可以校驗磁盤文件（例如“ib_logfile”,“*.ibd”文件等日志，索引文件）的結(jié)構(gòu)的完整性，如果結(jié)構(gòu)出現(xiàn)損壞，就會導(dǎo)致清除操作發(fā)生問題，甚至導(dǎo)致數(shù)據(jù)庫崩潰。利用上述參數(shù)值，可以禁止執(zhí)行后臺循環(huán)，來避免上述危險的發(fā)生。

上述兩種模式，在一般情況下不會導(dǎo)致數(shù)據(jù)的丟失，而其余的模式就容易導(dǎo)致數(shù)據(jù)不完整性的發(fā)生。如果設(shè)置為3，例如“innodb_force_recovery=3”，表示恢復(fù)后不回滾事務(wù)。當在當前數(shù)據(jù)庫中進行了一些事務(wù)性的操作，在事務(wù)沒有正常關(guān)閉的情況下，對于該模式來說，會強制性認為事務(wù)已經(jīng)關(guān)閉，而且不會回滾未關(guān)閉的事務(wù)，這很容易導(dǎo)致當前數(shù)據(jù)庫中的數(shù)據(jù)發(fā)生錯誤或者意外改變。如果設(shè)置為4，例如“innodb_force_recovery=4”，表示如果插入到緩沖區(qū)中的合并操作導(dǎo)致數(shù)據(jù)庫崩潰，則禁止執(zhí)行該操作。使用該模式，可能造成索引出現(xiàn)問題。解決方式是先導(dǎo)出數(shù)據(jù)，之后重新用相同的數(shù)據(jù)庫恢復(fù)數(shù)據(jù)，然后重建索引。

如果將其設(shè)置為5，例如“innodb_force_recovery=5”，表示啟動數(shù)據(jù)庫時忽略撤銷日志，InnoDB引擎將未完成的事務(wù)視作已完成，該模式不執(zhí)行Redo日志掃描和比對。如果設(shè)置為6，表示在啟動數(shù)據(jù)庫時，忽略與恢復(fù)相關(guān)的前滾日志。即如果在宕機時，“ib_logfile1”等日志文件中數(shù)據(jù)發(fā)生損壞，造成無法讀取日志或者讀取的是錯誤的信息，使用該模式將其忽略。這樣，在重啟之后，一些需要重做的事務(wù)操作被忽略，可能會導(dǎo)致數(shù)據(jù)的丟失。因為在重做日志中存放了多條日志信息，如果其中某條日志信息出現(xiàn)損壞，那么所有的日志信息都會被拋棄，導(dǎo)致丟失相關(guān)的事務(wù)操作，自然會出現(xiàn)數(shù)據(jù)的丟失。