MySQL 9.0 發行說明
REPAIR [NO_WRITE_TO_BINLOG | LOCAL]
TABLE tbl_name [, tbl_name] ...
[QUICK] [EXTENDED] [USE_FRM]
REPAIR TABLE 修復可能損毀的表格，僅適用於特定儲存引擎。
雖然通常您永遠不需要執行 REPAIR TABLE，但如果發生災難，此陳述式很有可能從 MyISAM 表格中取回所有資料。如果您的表格經常損毀，請嘗試找出原因，以消除使用 REPAIR TABLE 的需求。請參閱章節 B.3.3.3，「如果 MySQL 一直當機，該怎麼辦？」，以及章節 18.2.4，「MyISAM 表格問題」。
REPAIR TABLE 會檢查資料表是否需要升級。如果需要，它會執行升級，並遵循與 CHECK TABLE ... FOR UPGRADE 相同的規則。有關詳細資訊，請參閱 第 15.7.3.2 節，「CHECK TABLE Statement」。
重要
在執行資料表修復操作之前，請先備份資料表；在某些情況下，此操作可能會導致資料遺失。可能的原因包括但不限於檔案系統錯誤。請參閱 第 9 章，「備份與還原」。
如果在
REPAIR TABLE操作期間伺服器關閉，則重新啟動後，必須立即對該資料表執行另一個REPAIR TABLE陳述式，然後才能對其執行任何其他操作。在最糟糕的情況下，您可能會得到一個新的乾淨索引檔案，其中沒有關於資料檔案的資訊，然後您執行的下一個操作可能會覆寫資料檔案。這是一種不太可能但有可能發生的情況，強調了首先進行備份的價值。如果來源上的資料表損毀，並且您在其上執行
REPAIR TABLE，則對原始資料表所做的任何變更都不會傳播到複本。
REPAIR TABLE 適用於 MyISAM、ARCHIVE 和 CSV 資料表。對於 MyISAM 資料表，預設情況下，它的效果與 myisamchk --recover tbl_name 相同。此陳述式不適用於視圖。
分割區資料表支援 REPAIR TABLE。但是，USE_FRM 選項不能在分割區資料表上與此陳述式一起使用。
您可以使用 ALTER TABLE ... REPAIR PARTITION 來修復一個或多個分割區；有關詳細資訊，請參閱 第 15.1.9 節，「ALTER TABLE Statement」和 第 26.3.4 節，「分割區維護」。
NO_WRITE_TO_BINLOG或LOCAL預設情況下，伺服器會將
REPAIR TABLE陳述式寫入二進制日誌，以便將其複製到複本。要禁止記錄，請指定可選的NO_WRITE_TO_BINLOG關鍵字或其別名LOCAL。QUICK如果您使用
QUICK選項，REPAIR TABLE會嘗試僅修復索引檔案，而不修復資料檔案。這種修復類型與 myisamchk --recover --quick 所完成的修復類似。EXTENDED如果您使用
EXTENDED選項，MySQL 會逐列建立索引，而不是一次使用排序建立一個索引。這種修復類型與 myisamchk --safe-recover 所完成的修復類似。USE_FRM如果
.MYI索引檔案遺失或其標頭損壞，則可以使用USE_FRM選項。此選項會告知 MySQL 不要信任.MYI檔案標頭中的資訊，並使用資料字典中的資訊重新建立它。這種修復方式無法使用 myisamchk 完成。注意僅當您無法使用常規
REPAIR模式時，才使用USE_FRM選項。告知伺服器忽略.MYI檔案會使儲存在.MYI中的重要資料表元資料無法用於修復程序，這可能會造成有害的後果目前的
AUTO_INCREMENT值會遺失。資料表中已刪除記錄的連結會遺失，這表示已刪除記錄的可用空間之後會保持未被使用。
.MYI標頭會指出資料表是否已壓縮。如果伺服器忽略此資訊，則無法判斷資料表是否已壓縮，而修復可能會導致資料表內容的變更或遺失。這表示不應將USE_FRM用於壓縮的資料表。無論如何，這應該不是必要的：壓縮的資料表是唯讀的，因此它們不應該損壞。
如果您將
USE_FRM用於由與目前正在執行的 MySQL 伺服器版本不同的版本所建立的資料表，則REPAIR TABLE不會嘗試修復資料表。在這種情況下，REPAIR TABLE傳回的結果集中會包含一行，其Msg_type值為error，而Msg_text值為Failed repairing incompatible .FRM file。如果使用
USE_FRM，REPAIR TABLE不會檢查資料表是否需要升級。
REPAIR TABLE 會傳回一個結果集，其中包含下表中顯示的欄位。
| 欄位 | 值 |
|---|---|
Table |
資料表名稱 |
Op |
一律為 repair |
Msg_type |
status、error、info、note 或 warning |
Msg_text |
資訊訊息 |
對於每個已修復的資料表，REPAIR TABLE 陳述式可能會產生多行資訊。最後一行的 Msg_type 值為 status，而 Msg_test 通常應為 OK。對於 MyISAM 資料表，如果您未收到 OK，則應嘗試使用 myisamchk --safe-recover 進行修復。（REPAIR TABLE 並未實作 myisamchk 的所有選項。使用 myisamchk --safe-recover，您也可以使用 REPAIR TABLE 不支援的選項，例如 --max-record-length。）
REPAIR TABLE 資料表會捕捉並擲回將資料表統計資訊從舊的損毀檔案複製到新建立的檔案時發生的任何錯誤。例如。如果 .MYD 或 .MYI 檔案的所有者的使用者 ID 與 mysqld 程序的使用者 ID 不同，則除非 mysqld 是由 root 使用者啟動，否則 REPAIR TABLE 會產生「無法變更檔案擁有權」錯誤。
您可以透過設定某些系統變數來提高 REPAIR TABLE 的效能。請參閱 第 10.6.3 節，「最佳化 REPAIR TABLE 陳述式」。
如果資料表包含 5.6.4 之前的舊時間欄位格式，REPAIR TABLE 會升級資料表；也就是說，缺乏分數秒精度的 TIME、DATETIME 和 TIMESTAMP 欄位。