REPAIR [LOCAL | NO_WRITE_TO_BINLOG] TABLE

    tbl_name [, tbl_name] ... [QUICK] [EXTENDED] [USE_FRM]

REPAIR TABLE用于修復被破壞的表。默認情況下，REPAIR TABLE與myisamchk --recover tbl_name具有相同的效果。REPAIR TABLE對MyISAM和ARCHIVE表起作用。請參見15.1節，“MyISAM存儲引擎”, 15.8節，“ARCHIVE存儲引擎”。

通常，您基本上不必運行此語句。但是，如果災難發生，REPAIR TABLE很有可能從MyISAM表中找回所有數據。如果您的表經常被破壞，您應該盡力找到原因，以避免使用REPAIR TALBE。請參見A.4.2節，“如果MySQL依然崩潰，應作些什么”。同時也見15.1.4節，“MyISAM表方面的問題”。

本語句會返回一個含有以下列的表：

對于每個被修復的表，REPAIR TABLE語句會產生多行的信息。上一行含有一個Msg_type狀態值。Msg_test通常應為OK。如果您沒有得到OK，您應該嘗試使用myisamchk --safe-recover修復表，因為REPAIR TABLE尚不會執行所有的myisamchk選項。我們計劃在將來使它的靈活性更強。

如果給定了QUICK，則REPAIR TABLE會嘗試只修復索引樹。這種類型的修復與使用myisamchk --recover --quick相似。

如果您使用EXTENDED，則MySQL會一行一行地創建索引行，代替使用分類一次創建一個索引。這種類型的修復與使用myisamchk --safe-recover相似。

對于REPAIR TABLE，還有一種USE_FRM模式可以利用。如果.MYI索引文件缺失或標題被破壞，則使用此模式。在這種模式下，MySQL可以使用來自.frm文件重新創建.MYI文件。這種修復不能使用myisamchk來完成。 注釋：只能在您不能使用常規REPAIR模式是，才能使用此模式。.MYI標題包含重要的表元數據（特別是，當前的AUTO_INCREMENT值和Delete鏈接）。這些元數據在REPAIR...USE_FRM中丟失。如果表被壓縮，則不能使用USE_FRM。因為本信息也存儲在.MYI文件中。

REPAIR TABLE語句被寫入二進制日志中，除非使用了自選的NO_WRITE_TO_BINLOG關鍵詞（或其別名LOCAL）。

警告：如果在REPAIR TABLE運行過程中，服務器停機，則在重新啟動之后，在執行其它操作之前，您必須立刻對表再執行一個REPAIR TABLE語句。（通過制作一個備份來啟動是一個好辦法。）再最不利情況下，您可以有一個新的干凈的索引文件，不含有關數據文件的信息。然后，您執行的下一個操作會覆蓋數據文件。這很少發生，但是是有可能的。