誤刪 ibdata1 與 ib_logfile 後利用可傳輸表空間恢復 MySQL 數據實戰

事故現場

用戶嘗試開啟 Binlog 重啟失敗，隨後刪除 ibdata1、ib_logfile0/1，MySQL 能正常啟動（自動重建系統表空間），但 SHOW TABLES 可見表名，SELECT 卻報 ERROR 1146: Table doesn't exist，錯誤日誌提示 Cannot open table ... from the internal data dictionary of InnoDB though the .frm file exists。

恢復原理：可傳輸表空間

InnoDB 獨立表空間模式下，每張表擁有 .ibd 數據檔與 .frm 定義檔。若表結構一致，可通過 DISCARD/IMPORT TABLESPACE 將孤立的 .ibd 掛載回新建的表定義中，實現數據找回。

標準恢復步驟

1. 備份原數據目錄下的 .frm、.ibd 至安全位置（如 /backup/）。
2. 在 MySQL 中重建同名表，**表結構必須與原表完全一致**（列名、類型、順序）。
3. ALTER TABLE t DISCARD TABLESPACE; 丟棄新建表的空 .ibd。
4. 將備份的 .ibd 複製回目錄，修正擁有者 chown mysql:mysql。
5. ALTER TABLE t IMPORT TABLESPACE; 掛載數據檔。
6. FLUSH TABLE t; 刷新表定義快取，驗證 SELECT * FROM t; 正常。

實測驗證與關鍵發現

場景 1：新建表結構與原表完全一致，僅導入 .ibd

✅ 成功，數據完整可讀。

場景 2：新建表結構與原表完全一致，導入 .frm + .ibd

✅ 成功，FLUSH TABLE 後列名恢復為原定義。

場景 3：新建表結構**不一致**（列較少/類型不同），僅導入 .ibd

⚠️ 僅能讀取前 N 列（與新定義匹配的列），其餘列數據不可訪問。

場景 4：新建表結構**不一致**，導入 .frm + .ibd

❌ FLUSH TABLE 後報 Table doesn't exist，數據字典與表空間元數據不匹配導致表不可用。

場景 5：列類型不兼容（如 DATETIME 改為 VARCHAR）

💥 SELECT 瞬間導致 MySQL 進程崩潰（Lost connection to MySQL server during query）。

系統表恢復補充

刪除 ibdata1 會導致 mysql 庫下 5 張 InnoDB 系統表不可用：

innodb_index_stats, innodb_table_stats,
slave_master_info, slave_relay_log_info, slave_worker_info

需手動重建（參考 MySQL 官方文檔或 Percona 部落格腳本）。

最佳實踐總結

• **前提**：數據庫正常關閉（SHUTDOWN 或 systemctl stop）後刪除系統表空間檔案，保證 .ibd 處於一致狀態。
• **重建表結構必須 100% 一致**（含列名、類型、順序、字元集、排序規則）。
• **僅複製 .ibd 回原目錄**，無需複製 .frm（新建表已生成）。
• 執行 IMPORT TABLESPACE 後務必 FLUSH TABLE 驗證。
• 系統表空間損壞時，優先考慮從實體備份（XtraBackup）或邏輯備份（mysqldump）恢復，可傳輸表空間僅適用於用戶表救援。

參考資料

• MySQL 官方文檔：Copying Tablespaces to Another Server
• DBA StackExchange：Cannot open table mysql/innodb_index_stats