數據庫毀壞發生的原因有許多，且程度各不相同。如果幸運的話，可能是一兩個表的小毀壞（例如，如果您的機器由於斷電而暫時停機）。如果不是這樣，可能需要置換整個的數據目錄（例如，如果某個磁盤癱瘓而且數據目錄在它上）。在其他情況下也需要恢復操作，例如，當用戶錯誤地刪除數據庫或表時，或者錯誤地刪除表的內容時。不論這些不幸的事件發生是由於什麼原因，都需要恢復它們。
如果表被毀壞但沒有丟失，可試著用myisamchk 或isamchk 來修復它們。如果修復實用程序能修復它們，就根本沒有必要使用備份文件。表的修復過程將在第13 章討論。如果表被丟失或不能修復，則需要恢復它們。
恢復過程包括兩個信息源：備份文件和更新日志。備份文件將表恢復到進行該備份時的狀態。但是，在備份和故障發生這段時間中，表通常已經被修改。更新日志包含了用來完成這些修改的查詢。可以通過將更新日志作為對MySQL的輸入來重復這些查詢（這就是為什麼
應該允許更新日志的原因。如果您還沒有使更新日志有效，現在趕快做，並在進一步讀取之前生成一個新的備份）。
恢復過程根據必須恢復的信息的多少而變化。事實上，恢復整個數據庫比恢復單個的表要容易，因為對數據庫應用更新日志比對表要容易。
恢復整個數據庫
首先，如果要恢復的數據庫是含有授權表的MySQL數據庫，將需要使用--skip-grant-tables選項運行服務器。否則，服務器將抱怨無法找到授權表。在恢復表之後，執行MySQLadminflush-privileges 來告訴服務器加載授權表，並用它們啟動。
將原數據庫目錄的內容拷貝到其他的地方。例如，您可能會在稍後用它們進行崩潰表的事後分析檢查（post-mortem examination）。
用最新的備份文件重新加載數據庫。如果您打算使用由mysqldump 加載的文件，則需要將它們作為MySQL的輸入。如果打算使用從數據庫中直接拷貝的文件（如，用tar 或c p），則將它們直接拷貝回到該數據庫目錄中。但是，在這種情況下，應該在拷貝這些文件之前關閉服務器，然後再重新啟動它。
用更新日志重做在進行備份後又修改了數據庫表的查詢。對於所有可用的更新日志，可使用它作為mysql的輸入。指定--one-database 選項，使MySQL只對想要恢復的數據庫執行查詢。如果您知道需要使用所有的更新日志文件，可在包含日志的目錄中使用
下列命令：
% ls -t -r -l update.(0-9)* | xargs cat | MySQL--one-database db_name
ls 命令產生更新日志文件的單列列表，更新日志文件根據服務器生成的順序進行排序（要知道，如果您修改了其中的任何文件，排序的順序都將改變，這將導致更新日志按錯誤的順序使用）。
您很可能必須使用某些更新日志。例如，如果自備份以來所產生的日志命名為update.392、update.393 等等，可以重新運行它們中的命令：
% mysql--one-database db_name < updata.392 % MySQL--one-database db_name < updata.393
如果正在運行恢復並打算使用更新日志恢復由於失策的DROP DATABASE、DROPTABLE或DELETE 語句而丟失的信息，應確保先從更新日志中刪除這些語句。
恢復單個的表
恢復單個表是很困難的。如果有通過mysqldump 生成的備份文件並且它恰好不包含您想要的表數據，則需要抽取相關的行並用它們作為mysql的輸入，這部分較容易。困難的是抽取應用於該表的更新日志的片段。您會發現： MySQL_find_rows 實用程序對這方面有幫助，它可以從更新日志中抽取多行查詢。
另一種可能性是用另一個服務器恢復整個數據庫，然後將所要的該表的文件拷貝到原始數據庫中。這實際很容易！在將文件拷貝回數據庫目錄時，應確保原始數據庫的服務器關閉。
