MySQL 表修復與優化命令詳解：REPAIR TABLE 與 OPTIMIZE TABLE 實戰用法

命令對照

REPAIR TABLE 參數與策略

REPAIR TABLE tbl_name [QUICK] [EXTENDED] [USE_FRM];

• QUICK：只修復索引檔（.MYI），不掃描資料檔，速度最快，適用索引損壞、資料完好。
• EXTENDED：逐行重建索引，極慢，最後手段。
• USE_FRM：.MYI 遺失或頭部損壞時，用 .frm 定義重建索引。

OPTIMIZE TABLE 執行機制

1. 建立臨時表複製資料（INSERT INTO tmp SELECT * FROM tbl ORDER BY PK）。
2. 刪除原表，重命名臨時表。
3. 重建索引、更新統計資訊。

InnoDB 實際執行 ALTER TABLE ... ENGINE=InnoDB（重建聚簇索引）。

何時執行

• REPAIR：出現 Table is marked as crashed、Can't open file .MYI、查詢結果不完整、CHECK TABLE 回報錯誤。
• OPTIMIZE：大量 DELETE/UPDATE 後、定期維護（週/月）、Data_free 佔比 > 20%、SHOW TABLE STATUS 顯示碎片大。

實戰流程

-- 1. 檢查
CHECK TABLE tbl_name;
-- 或
CHECK TABLE tbl_name FAST;  -- 僅檢查未正確關閉的表
CHECK TABLE tbl_name EXTENDED; -- 逐行掃描

-- 2. 修復
REPAIR TABLE tbl_name;           -- 標準修復
REPAIR TABLE tbl_name USE_FRM;   -- 索引檔遺失

-- 3. 優化（修復完成後）
OPTIMIZE TABLE tbl_name;

-- 4. 驗證
CHECK TABLE tbl_name;
ANALYZE TABLE tbl_name;  -- 更新統計資訊

自動化維護腳本（Cron 範例）

#!/bin/bash
# 每週日凌晨 3 點執行
mysqlcheck --auto-repair --optimize --all-databases -u root -p'password' > /var/log/mysql_weekly_maintenance.log 2>&1

注意事項

• 操作前**務必備份**（mysqldump 或檔案級快照）。
• 大表執行時間長，規劃維護窗口，避開業務高峰。
• InnoDB 不支援 REPAIR TABLE，損壞需從備份恢復或 innodb_force_recovery。
• 磁碟空間需 ≥ 表大小 2 倍（重建臨時表）。