表損壞是 MyISAM 時代 DBA 的噩夢，狀包含查詢中斷、.MYI 遺失、錯誤代碼 135/144/145、資料檔截斷等。本文提供分級修復策略：從最快的「僅修索引」到「重建索引檔」，再到「從備份恢復」與「無備份重建」，並說明關鍵工具 myisamchk 參數與操作細節。

損壞典型徵兆

• tbl_name.frm is locked against change
• Can't find file: 'tbl_name.MYI' (Errcode: ###)
• Got error ### from table handler（135 除外）
• Unexpected end of file / Record file is crashed

分級修復策略

Level 1：快速安全修復（僅重建索引，不動資料檔）

myisamchk -r -q tbl_name
isamchk -r -q tbl_name

• -r：恢復模式
• -q：快速模式，僅依索引檔重建，不掃描資料檔
• 適用：索引檔輕微損壞、資料檔完整

Level 2：標準修復（允許修改資料檔）

myisamchk -r tbl_name
isamchk -r tbl_name

• 刪除錯誤記錄與已刪除記錄，重建索引檔
• 適用：Level 1 失敗、資料檔有殘留垃圾資料

Level 3：安全恢復模式（舊版演算法，較慢但穩健）

myisamchk --safe-recover tbl_name
isamchk --safe-recover tbl_name

• 處理常規模式無法修復的邊界情況（如索引樹結構嚴重破損）
• 速度較慢，作為 Level 2 失敗後的備選

Level 4：索引檔頭部損壞/遺失 — 重建索引檔

前提：.frm 表定義檔完整，.MYD 資料檔完整

1. 進入資料庫目錄：cd /var/lib/mysql/db_name/
2. 移動資料檔備份：mv tbl_name.MYD /safe/place/
3. 用 .frm 重建空表：

   mysql db_name
   mysql> DELETE FROM tbl_name;
   mysql> quit

4. 將備份資料檔複製回來（非移動，保留副本）：cp /safe/place/tbl_name.MYD ./
5. 執行標準修復：myisamchk -r -q tbl_name（此時應成功）

Level 5：有備份檔案 — 從備份恢復

1. 恢復 .frm、.MYD、.MYI 三檔
2. 執行 CHECK TABLE 驗證
3. 若仍有問題，套用 Level 1-3 標準修復

Level 6：.frm 定義檔也損壞 — 終極重建

前提：記得 CREATE TABLE 陳述式或有 Schema 備份

1. 備份 .MYD 資料檔
2. 刪除資料庫目錄下該表所有檔案（.frm .MYD .MYI）
3. 在 mysql 中執行 CREATE TABLE 重建結構
4. 退出 mysql，將原始 .MYD 覆蓋新建立的空資料檔
5. 回到 Level 2 或 Level 1 修復索引

關鍵工具參數速查

參數	用途
-r / --recover	恢復模式（標準修復）
-q / --quick	快速模式，不掃描資料檔
--safe-recover	安全恢復模式（舊演算法）
--force	強制覆蓋舊暫存檔
--analyze	分析索引分佈（配合優化）

預防勝於治療

1. 定期備份：mysqldump --single-transaction --master-data=2（InnoDB）或 mysqlhotcopy（MyISAM）
2. 啟用檢查和修復自動化：CHECK TABLE 排程 + 告警
3. 避免強制關機：UPS、優雅關機腳本 mysqladmin shutdown
4. 磁碟健康監控：SMART、RAID 卡告警、檔案系統 fsck
5. 遷移至 InnoDB：崩潰安全、支援事務、無需離線修復

---

表損壞修復是「外科手術」，分級策略能最大化搶救成功率。但請記住：最好的修復是不需要修復——完備的備份策略與 InnoDB 引擎，才是資料安全的真正基石。