MySQL 數據庫損壞快速修復指南：myisamchk 與 mysqlcheck 實戰

前言

MySQL 數據庫在長期運行或遭遇意外斷電、磁碟故障後，可能出現索引損壞、數據不一致等問題。針對 MyISAM 存儲引擎，MySQL 官方提供了兩大核心修復工具：myisamchk（離線修復）與 mysqlcheck（在線熱修復）。本文將詳細對比兩者的適用場景、操作步驟及避坑指南，助你快速恢復數據可用性。

方案一：myisamchk 離線深度修復

適用場景：嚴重索引損壞、數據量大、可接受短暫停機窗口。

核心原理：直接讀取數據文件（.MYD）與索引文件（.MYI），重建 B+ 樹索引，需獨佔文件鎖，因此必須停止 MySQL 服務。

操作步驟（以 Discuz 數據庫為例）

# 1. 停止 MySQL 服務
service mysql stop

# 2. 執行修復命令（-r 參數表示修復模式）
myisamchk -r /var/lib/mysql/discuz/*.MYI

# 3. 啟動 MySQL 服務
service mysql start

關鍵說明：

• -r（recover）：默認修復模式，可修復大多數索引錯誤，保留數據完整性。
• 路徑需指向具體數據庫目錄下的 *.MYI 文件，支持通配符批量處理。
• 修復過程中會生成臨時文件，確保磁碟剩餘空間 ≥ 數據庫大小的 1.5 倍。

方案二：mysqlcheck 在線熱修復

適用場景：業務不允許停機、輕微索引不一致、常規維護檢查。

核心優勢：無需停止服務，通過 SQL 協議與 Server 交互，支持表級鎖定，對讀寫影響較小。

操作示例

# 修復 discuz 數據庫下所有表
mysqlcheck -r discuz

# 修復指定表
mysqlcheck -r discuz.pre_forum_thread

# 僅檢查不修復（生產環境建議先檢查）
mysqlcheck -c discuz

參數對照表：

避坑指南：慎用 -f 強制修復

警告：無論使用 myisamchk 還是 mysqlcheck，嚴禁常規使用 -f（--force）參數。

原因：-f 會在常規修復失敗時，強制刪除損壞的數據行以完成索引重建，導致不可逆的數據丟失。僅在「備份不可用、業務允許少量數據丟失、且已嘗試常規修復無效」的極端情況下，經 DBA 評估後方可使用。

最佳實踐建議

1. 優先備份：修復前務必複製 .MYD、.MYI、.frm 文件到安全位置。
2. 分級處理：例行維護用 mysqlcheck -c；發現錯誤先嘗試 mysqlcheck -r；無效再停機用 myisamchk -r。
3. 引擎遷移：核心業務表建議遷移至 InnoDB，利用事務日誌實現崩潰安全恢復，從根源避免 MyISAM 修復痛點。

總結

myisamchk 是重武器，徹底但需停機；mysqlcheck 是輕騎兵，隨時可用但能力有限。建立「每日 mysqlcheck -c 巡檢 + 月度 mysqlcheck -o 優化」的維護體系，才是守護數據庫健康的長久之計。