MySQL 9.0 版本注意事項
若要調查資料庫頁面損毀，您可以使用 SELECT ... INTO OUTFILE 從資料庫傾印您的資料表。通常，以這種方式取得的大部分資料都是完好的。嚴重的損毀可能會導致 SELECT * FROM 陳述式或 tbl_nameInnoDB 背景操作意外結束或斷言，甚至導致 InnoDB 向前復原當機。在這種情況下，您可以使用 innodb_force_recovery 選項，強制 InnoDB 儲存引擎啟動，同時防止背景操作執行，以便您可以傾印您的資料表。例如，您可以將下列行新增至選項檔案的 [mysqld] 區段，然後重新啟動伺服器。
[mysqld]
innodb_force_recovery = 1有關使用選項檔案的資訊，請參閱第 6.2.2.2 節，「使用選項檔案」。
警告
僅在緊急情況下才將 innodb_force_recovery 設定為大於 0 的值，以便您可以啟動 InnoDB 並傾印您的資料表。在執行此操作之前，請確保您擁有資料庫的備份副本，以防需要重新建立資料庫。值為 4 或更大可能會永久損壞資料檔案。僅在您已在資料庫的單獨實體副本上成功測試設定之後，才在生產伺服器實例上使用 innodb_force_recovery 設定為 4 或更大。強制 InnoDB 復原時，您應該始終從 innodb_force_recovery=1 開始，並僅在必要時逐漸增加值。
innodb_force_recovery 預設值為 0（正常啟動，不強制復原）。innodb_force_recovery 的允許非零值為 1 到 6。較大的值包含較小值的功能。例如，值為 3 包含值 1 和 2 的所有功能。
如果您能夠使用 innodb_force_recovery 值為 3 或更小的值傾印您的資料表，則您相對安全，只會遺失一些損毀個別頁面上的資料。值為 4 或更大被認為是危險的，因為資料檔案可能會永久損壞。值為 6 被認為是極端的，因為資料庫頁面會保持在過時的狀態，這反過來可能會將更多損毀引入 B 樹和其他資料庫結構。
作為安全措施，當 innodb_force_recovery 大於 0 時，InnoDB 會防止 INSERT、UPDATE 或 DELETE 操作。innodb_force_recovery 設定為 4 或更大會將 InnoDB 置於唯讀模式。
1(SRV_FORCE_IGNORE_CORRUPT)即使偵測到損毀的頁面，仍允許伺服器執行。嘗試使
SELECT * FROM跳過損毀的索引記錄和頁面，這有助於傾印表格。tbl_name2(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 表格。當 innodb_force_recovery 值大於 3 時，也支援 DROP TABLE。當 innodb_force_recovery 值大於 4 時，不允許 DROP TABLE。
如果您知道給定的表格在回滾時會導致意外結束，您可以刪除它。如果您遇到由失敗的大量匯入或 ALTER TABLE 引起的失控回滾，您可以終止 mysqld 程序，並將 innodb_force_recovery 設定為 3，以在沒有回滾的情況下啟動資料庫，然後 DROP 導致失控回滾的表格。
如果表格資料內的損毀阻止您傾印整個表格內容，帶有 ORDER BY 子句的查詢可能能夠傾印損毀部分之後的表格部分。primary_key DESC
如果啟動 InnoDB 需要較高的 innodb_force_recovery 值，則可能存在損毀的資料結構，這可能會導致複雜的查詢（包含 WHERE、ORDER BY 或其他子句的查詢）失敗。在這種情況下，您可能只能執行基本的 SELECT * FROM t 查詢。