MySQL 資料表損壞：九大成因、五類癥狀、九項預防與四階段修復全流程

MySQL 表損壞是 DBA 必修課。本文系統梳理成因、癥狀、預防與分級修復流程，涵蓋 MyISAM 與 InnoDB 兩大引擎。

一、九大常見成因

1. 伺服器突斷電導致資料檔損壞
2. 強制關機，未先停止 MySQL 服務
3. mysqld 寫入時被 kill -9 強制終止
4. myisamchk 與 mysqld 同時操作同一表
5. 磁碟壞軌/控制器故障
6. 作業系統死機/核心恐慌
7. MySQL 本身 Bug（升級穩定版可避免）
8. 記憶體不足導致 OOM Killer 殺進程
9. 硬體 RAID 卡快取掉電無電池保護

二、五類典型癥狀

1. Incorrect key file for table: '...'. Try to repair it
2. 查詢找不到行或返回不完整資料
3. Table 'p' is marked as crashed and should be repaired
4. Can't open file: 'xxx.MYI' (errno: 145)
5. ERROR 1034 (HY000): Incorrect key file

三、九項預防措施

1. 定期 CHECK TABLE（無需停服務）或 myisamchk（需停服務）
2. 大量更新/刪除後執行 OPTIMIZE TABLE 整理碎片
3. 關機前優雅停止 mysqld，禁用 kill -9
4. 部署 UPS 不間斷電源
5. 使用最新穩定版 MySQL/Percona/MariaDB
6. InnoDB 定期跑 innodb_tablespace_monitor 檢查表空間完整性
7. 資料盤做 RAID 1/10，降低單點故障風險
8. 資料庫專機運行，避免業務服務爭搶資源導致死機
9. 定期離線/線上備份（最核心防線）

四、MyISAM 四階段修復流程

階段 1：檢查

myisamchk *.MYI          # 快速檢查
myisamchk -e *.MYI       # 延伸檢查
myisamchk -s *.MYI       # 靜默模式
# 僅修復報錯的表

階段 2：簡單安全修復

myisamchk -r -q tbl_name   # 快速恢復模式（僅重建索引）
# 失敗則
myisamchk -r tbl_name      # 恢復模式（刪除錯誤記錄、重建索引）
# 仍失敗則
myisamchk --safe-recover tbl_name  # 安全恢復（舊演算法，較慢但穩）

修復前務必備份 .MYD、.MYI。

階段 3：困難修復（索引檔前 16K 損壞/遺失）

1. 移動 .MYD 到安全處
2. 用 .frm 重建空表：

   mysql db_name
   SET AUTOCOMMIT=1;
   TRUNCATE TABLE tbl_name;  -- 或 DELETE FROM tbl_name
   quit

3. 將舊 .MYD 複製回新建的資料檔
4. 回階段 2 執行 myisamchk -r -q

或一鍵：REPAIR TABLE tbl_name USE_FRM;

階段 4：極度困難（.frm 也損壞）

1. 從備份還原 .frm → 回階段 3
2. 或從備份還原 .MYI → 回階段 2
3. 無備份但記得 CREATE TABLE：在別庫建同結構表，複製 .frm/.MYI 回來 → 階段 2/3

五、InnoDB 損壞應對策略

InnoDB 具備崩潰恢復能力，若資料頁損壞：

1. 嘗試 SELECT * INTO OUTFILE 導出完好資料
2. 若崩潰無法啟動，編輯 my.cnf 加入 innodb_force_recovery = 1..6 強制啟動導出：

• 值越大包含越多保護措施，≥4 可導出多數資料，=6 風險最高。
• 設定 >0 時 InnoDB 禁止 INSERT/UPDATE/DELETE。
• 可 DROP/CREATE TABLE 移除壞表停止失控回滾。

表損壞不可怕，可怕的是「無備份、不演練」。建立「日檢、周優、月備、季演練」機制，才是根治之道。