MySQL 數據恢復全策略：從 myisamchk 修復到備份+Binlog 完整還原

數據庫損壞原因多樣（斷電、磁盤故障、誤操作），恢復策略需分級：修復 > 還原備份+重放 Binlog > 最後手段。本文系統梳理 MyISAM/InnoDB 表級與庫級恢復全流程。

第一梯隊：表修復 (無數據丟失、最快)

• MyISAM：myisamchk -r tbl_name 或 SQL REPAIR TABLE tbl_name。
• InnoDB：不可用 myisamchk。依賴崩潰恢復 (重啟自動)、innodb_force_recovery=1..6 分級搶救、或 CHECK TABLE 檢測。
• **修復成功 → 直接驗證業務，無需動備份。**

第二梯隊：備份文件 + Binlog 重放 (標準恢復)

核心原理

恢復點 = 最近一次全量備份 + 其後所有 Binlog 事務

前提：**必須開啟 Binlog (log-bin)**，且備份時記錄 Binlog 位點 (--master-data=2)。

恢復整個數據庫 (最簡單、最可靠)

1. 停止服務，備份損壞數據目錄 (供事後分析)。
2. 從全量備份恢復：
     邏輯備份：mysql -u root -p db_name < full_backup.sql
     物理備份：停服務 → 覆蓋 datadir → 啟動服務。
3. 重放 Binlog：
     獲取備份位點：head -30 full_backup.sql | grep 'CHANGE MASTER'
     依次應用：mysql -u root -p --one-database db_name < binlog.xxx
     或批量：mysqlbinlog binlog.000001 binlog.000002 | mysql -u root -p --one-database db_name
4. 驗證數據完整性、業務功能。

恢復單張表 (複雜、易出錯)

1. 從全量備份中提取目標表結構+數據 (用 sed/awk 或 mysqldump -t db tbl 重導)。
2. 在臨時庫恢復該表。
3. 提取 Binlog 中針對該表的事件 (極難) → **推薦用 mysqlbinlog --database=db --table=tbl 過濾**。
4. 或**整庫恢復到臨時實例**，再 SELECT * INTO OUTFILE 導出 → 導入生產庫。

第三梯隊：誤操作緊急搶救 (DROP TABLE / DELETE 無 WHERE)

1. **立即停止寫入** (只讀模式/防火牆隔離)，防止 Binlog 被新事務覆蓋/推進。
2. 若有 --master-data=2 備份：按第二梯隊恢復到誤操作前位點 (mysqlbinlog --stop-position=XXX)。
3. 若無備份但開啟 Binlog：
     mysqlbinlog --start-datetime="..." --stop-datetime="..." binlog.* | mysql -u root -p
     精確截取誤操作前的事務重放。
4. InnoDB 表誤 DROP：innodb_force_recovery=1 啟動 → 可能在數據字典中殘留表定義 → 用 CREATE TABLE ... ENGINE=InnoDB 重建結構 → ALTER TABLE ... DISCARD/IMPORT TABLESPACE 掛載 .ibd (高風險，需專家介入)。

預防體系 (比恢復更重要)

總結

1. **優先嘗試修復** (REPAIR TABLE/崩潰恢復)，成本最低。
2. **全庫恢復 + Binlog 重放** 是標準化、可驗證、風險可控的主流方案。
3. **單表恢復極其痛苦**，實際生產建議「整庫恢復到臨時實例 → 導出導入」。
4. **備份策略 = 恢復策略**，無備份則無恢復可能。