MySQL 表索引損壞排查與修復實戰

前言

下午上班時發現公司的 Dedecms 網站全頁報錯，查看 MySQL 錯誤日誌，赫然出現以下提示：

Table '.dedecmsv4dede_archives' is marked as crashed and should be repaired

訊息直指文章主表 dede_archives 索引損壞，必須立即修復。經過資料還原與原因排查，最終成功解決，現整理完整流程供參考。

快速修復步驟

1. 定位 MySQL 安裝目錄下的 bin/myisamchk 工具。
2. 在命令列執行：
   myisamchk -c -r ../data/dedecmsv4/dede_archives.MYI
3. 工具會自動重建索引，完成後重啟 MySQL 服務，網站恢復正常。

問題成因分析

錯誤編號為 145。常見原因包括：

• 高頻讀寫衝突：網站採用動態頁面，未生成靜態檔，導致 dede_archives 表頻繁被查詢與更新，索引極易損壞。
• 硬體或系統異常：資料庫伺服器突發斷電、在服務運行期間直接操作表檔（如複製、移動），均可能造成 MyISAM 表損壞而無法讀取。
• 其他不可預期因素：磁碟壞軌、記憶體錯誤、進程被強制殺死等。

MyISAM 表的三種修復模式

當嘗試修復損壞表時，可依嚴重程度選擇：

提示：若報臨時檔無法建立，請刪除殘留的臨時檔後重試。

進階修復：索引檔遺失或不可修復

若 .MYI 索引檔損壞嚴重或遺失，可利用資料檔 .MYD 與結構檔 .frm 重建：

1. 備份 tblName.MYD。
2. 重啟 MySQL，執行 DELETE FROM tblName; 清空表，同時生成新索引檔。
3. 停止服務，用備份的 .MYD 覆蓋新建的空資料檔。
4. 執行標準修復（第二種模式），依據資料與結構重建索引。

進階修復：結構檔 .frm 損壞

若 .frm 遺失但清楚原 CREATE TABLE 語句：

1. 備份資料與索引檔，刪除原表所有檔案。
2. 啟動 MySQL 並用原建表語句重建表，產生新 .frm。
3. 執行標準修復，確保索引一致性。

myisamchk 工具詳解

myisamchk 專為 MyISAM 表（.MYI/.MYD）設計，可獲取資訊、檢查、修復、優化。

常用調用方式

• 檢查單表：myisamchk [options] tbl_name
• 批次檢查資料庫目錄所有表：myisamchk /path/to/database_dir/*.MYI
• 掃描所有資料庫：myisamchk /path/to/datadir/*/*.MYI

推薦的快速檢查與自動修復指令

myisamchk --silent --fast /path/to/datadir/*/*.MYI          # 僅檢查
myisamchk --silent --force --fast --update-state \
  -O key_buffer=64M -O sort_buffer=64M \
  -O read_buffer=1M -O write_buffer=1M \
  /path/to/datadir/*/*.MYI                                 # 檢查並修復

執行前請確保無其他程序佔用表（停止 MySQL 或執行 FLUSH TABLES），否則會報 warning: clients are using or haven't closed the table properly。

總結

索引損壞雖屬低概率事件，但一旦發生影響極大。掌握 myisamchk 分級修復流程、平時做好備份與靜態化，能將風險降至最低。