Myisamchk 工具深度指南：MyISAM 表檢查、修復與磁碟空間規劃

為什麼需要 Myisamchk？

MySQL 資料庫往往包含成百上千張表，逐一人工檢查不切實際。myisamchk 是官方提供的 MyISAM 存儲引擎專用離線維護工具，能高效檢測、修復表損壞，堪比資料庫的「年度體檢儀」——早發現、早治療，避免小問題演變成災難性數據丟失。

一、大表必讀：記憶體參數調優

myisamchk 效能高度依賴可用記憶體，關鍵參數 -O（或 --set-variable）控制排序緩衝區大小。預設僅 3MB，對 GB 級大表嚴重不足。

建議配置策略

• 評估表大小：先用通配符或腳本篩選大表（如 myisamchk *.MYI 觀察耗時）。
• 調整排序緩衝：myisamchk -O sort_buffer_size=16M ...，16MB 為通用甜點，視機器記憶體上調至 64-256MB，但勿佔用超過物理記憶體 50%，免影響其他服務。
• 分批處理：大表單獨檢查，小表可批次，避免記憶體爭用。

二、修復前的磁碟空間紅線

修復過程需建立臨時檔案，空間需求嚴格：

• 基準需求：資料檔（.MYD）大小的 1 倍。例：2GB 表需至少 2GB 餘裕空間。
• 索引重建額外開銷：新舊索引檔（.MYI）並存期間再需 1 倍索引大小。
• 安全紅線：預留 資料檔 2 倍以上 空間（含索引重建緩衝）。

空間不足的應對

• --quick 模式：不重建資料檔，僅修復索引，大幅降低空間需求，但無法修復資料層損壞。
• --recover（或 -r）：採用排序緩衝重建索引，需約 資料量 2 倍 排序空間，能解決 90%+ 損壞，但「唯一鍵重複」等邏輯錯誤無效。

三、分級修復標準作業程序（SOP）

前置動作（強制）：

1. 停止 MySQL 服務（systemctl stop mysqld），防止寫入衝突。
2. 完整備份資料目錄（cp -a /var/lib/mysql /backup/mysql_$(date +%F)），哪怕工具再安全，備份是底線。

階段 1：快速檢查與標記

# 僅檢查，標記損壞表，更新狀態旗標
myisamchk --update-state /var/lib/mysql/db_name/*.MYI

後續修復可加 --fast 僅處理標記表，提升效率。

階段 2：快速安全修復（首選）

myisamchk -r -q /var/lib/mysql/db_name/tbl_name.MYI

• -r：恢復模式，刪除錯誤記錄、重建索引。
• -q：快速模式，不掃描資料檔，僅修復索引樹。
• 適用：索引損壞、資料檔完整。

階段 3：索引檔嚴重損壞/遺失

1. 移動資料檔備份：mv tbl_name.MYD /safe/path/
2. 用 .frm 結構檔重建空表：mysql -e "CREATE TABLE db_name.tbl_name ...;"（或用 mysqlfrm 反向生成 DDL）。
3. 覆回原資料檔：cp /safe/path/tbl_name.MYD /var/lib/mysql/db_name/
4. 執行 myisamchk -r -q 重建索引。

階段 4：結構檔（.frm）也損壞——終極方案

無法從 .frm 重建結構時，唯有從完整備份集（全量+增量 Binlog） 做時間點恢復（PITR）。這再次證明：備份策略才是最後防線，myisamchk 只是輔助手段。

四、進階技巧與避坑指南

• 通配符批次：myisamchk /var/lib/mysql/*/*.MYI 一鍵巡檢全庫。
• 單檔操作：可直接對 .MYD/.MYI 操作，無需進入 MySQL。
• 並發風險：絕不可在 MySQL 運行時對同表執行 myisamchk，會導致索引不一致甚至資料損壞。
• 版本匹配：工具版本需與 MySQL 服務端主版本一致（如 5.7 工具不可修 8.0 表）。

總結

Myisamchk 是 MyISAM 表維護的利器，核心在於「備份優先、記憶體充足、磁碟預留、分級修復」。但請牢記：InnoDB 已成主流，MyISAM 漸趨邊緣；若業務允許，遷移至 InnoDB 並善用 CHECK TABLE/REPAIR TABLE 線上命令與 innodb_force_recovery 才是長久之計。