MySQL InnoDB 表空間傳輸 (TST) 實戰：DISCARD/IMPORT 遷移大表避坑指南

適用場景

• **大表遷移** (億級行) 避免 `mysqldump` 導入極慢。
• **同版本、同架構** MySQL 實例間 (如 5.5→5.5, 5.6→5.6)。
• **文件系統級複製** 速度受限於磁盤/網絡 IO，遠快於邏輯導入。

核心前提：表空間 ID (Space ID) 必須一致

InnoDB 系統表空間 (`ibdata1`) 維護全局 `space_id` 計數器。每個獨立表空間 (`.ibd`) 創建時分配一個唯一 `space_id` 並寫入文件頭。**源庫 `.ibd` 的 `space_id` 必須等於目標庫該表的 `space_id`，否則 `IMPORT` 失敗報錯**：

ERROR 1030 (HY000): Got error -1 from storage engine
-- 錯誤日志：
InnoDB: tablespace id in file './db/t.ibd' is 2428, but in the InnoDB data dictionary they are 2430

標準遷移流程 (Space ID 一致時)

-- 1. 目標庫建表 (結構完全一致)
CREATE TABLE sysUser (...) ENGINE=InnoDB;

-- 2. 目標庫丟棄表空間 (產生新 space_id 佔位)
ALTER TABLE sysUser DISCARD TABLESPACE;

-- 3. 複製源庫 .ibd 文件到目標庫數據目錄
scp src:/var/lib/mysql/db/sysUser.ibd dst:/var/lib/mysql/db/

-- 4. 修改文件擁有者
chown mysql:mysql /var/lib/mysql/db/sysUser.ibd

-- 5. 目標庫導入表空間
ALTER TABLE sysUser IMPORT TABLESPACE;
-- Query OK, 0 rows affected (0.05 sec)  <-- 秒級完成億級遷移

Space ID 不一致的解決方案

情況 A：源 Space ID < 目標 Space ID (常見)

目標庫 `space_id` 已經更大，需**將目標庫 `space_id` 推進到源庫 `space_id` 以上**。

方法：批量創建/刪除臨時表消耗 Space ID

#!/usr/bin/env python
# 消耗 Space ID 腳本
import MySQLdb

conn = MySQLdb.connect(host='dst', user='root', passwd='xxx', db='db_test', charset='utf8')
cursor = conn.cursor()

# 計算差值：源 2428, 目標 2430 -> 已經超過，無需操作
# 若源 44132, 目標 2436 -> 需消耗 44132 - 2436 = 41696 個 ID
# 安全起見少消耗幾個，留餘量手動補齊
target_consume = 41690

for i in range(target_consume):
    cursor.execute("CREATE TABLE tmp_%d (id INT) ENGINE=InnoDB" % i)
    cursor.execute("DROP TABLE tmp_%d" % i)
    if i % 1000 == 0: print("Consumed %d" % i)

conn.close()

執行後，**重新執行標準流程 1-5 步** (目標庫重建表 → DISCARD → 複製 → IMPORT)。

情況 B：源 Space ID > 目標 Space ID (極少見，除非源庫頻繁建刪表)

同理，在目標庫消耗 ID 直到超過源庫。

MySQL 5.6+ 重大改進：無需匹配 Space ID

**MySQL 5.6 引入 `.cfg` 元數據文件**，`FLUSH TABLES ... FOR EXPORT` 生成 `.cfg`，`IMPORT TABLESPACE` 時通過 `.cfg` 驗證結構兼容性，**不再強制要求 Space ID 一致**，極大簡化遷移。

-- 源庫 (5.6+)
FLUSH TABLES sysUser FOR EXPORT;  -- 生成 sysUser.cfg
-- 複製 .ibd 和 .cfg 到目標庫
-- 目標庫
ALTER TABLE sysUser IMPORT TABLESPACE;  -- 直接成功

風險與局限 (必讀)

最佳實踐建議

1. 首選 `mysqldump` / `mydumper` / `xtrabackup`：邏輯/物理備份工具成熟、安全、支持流控、驗證、增量。
2. TST 僅作為極大表 (TB 級) 且停機窗口極短時的備選方案。
3. 必須在測試環境全流程演練**，驗證數據完整性 (行數、校驗和、業務查詢)。
4. MySQL 5.6+ 必須使用 `FOR EXPORT` 產生 `.cfg`**，避免 Space ID 麻煩。
5. 遷移後運行 `ANALYZE TABLE` 更新統計信息**，確保優化器生成正確計劃。