MySQL 重命名資料庫五大方案深度對比：從 RENAME DATABASE 到 Shell 自動化的演進之路

MySQL 重命名資料庫五大方案深度對比

MySQL 5.1.7 曾引入 RENAME DATABASE，5.1.23 因數據丟失風險緊急移除。生產環境修改庫名需採用變通方案。本文系統對比五種方案原理、優劣、適用場景與風險等級，助您根據業務約束選擇最優路徑。

方案一：RENAME DATABASE (已廢棄，極高風險)

RENAME DATABASE old_db TO new_db;

• 歷史：5.1.7 引入，5.1.23 移除。
• 缺陷：僅重命名目錄，不更新表內部元數據 (如視圖/存儲過程定義中的庫名)、不處理權限表、可能導致 .frm/.ibd 文件與數據字典不一致、崩潰恢復失敗。
• 結論：嚴禁生產使用，僅作歷史參考。

方案二：直接重命名數據目錄 (僅限 MyISAM、需停庫)

# 1. 停止服務
systemctl stop mysqld
# 2. 重命名 data 目錄下庫文件夾
mv /var/lib/mysql/old_db /var/lib/mysql/new_db
# 3. 啟動服務
systemctl start mysqld

• 前提：所有表必須為 MyISAM (InnoDB 共享表空間 ibdata1 存儲數據字典，目錄重命名會導致字典不一致)。
• 缺陷：需停機、不支援 InnoDB、權限表 (mysql.db/mysql.tables_priv) 中庫名不變、視圖/觸發器定義不更新。
• 適用：純 MyISAM 唯讀歸檔庫、測試環境快速克隆。

方案三：RENAME TABLE 逐表遷移 (標準元數據操作、秒級、零數據拷貝)

CREATE DATABASE new_db;
RENAME TABLE old_db.tbl1 TO new_db.tbl1, old_db.tbl2 TO new_db.tbl2, ...;
DROP DATABASE old_db;

• 原理：在同一實例內移動表元數據，物理 .ibd 文件不動 (獨立表空間) 或更新共享表空間指針。
• 優勢：極快 (毫秒級)、原子性 (單條 RENAME TABLE 原子)、支援 InnoDB/MyISAM 混合、無雙倍磁盤佔用。
• 自動化生成腳本：

  SELECT CONCAT('RENAME TABLE ', TABLE_SCHEMA, '.', TABLE_NAME, ' TO new_db.', TABLE_NAME, ';')
  FROM information_schema.TABLES WHERE TABLE_SCHEMA='old_db';

• 注意：外鍵約束需先刪除、視圖/存儲過程/觸發器需手動重建、權限需重新 GRANT。

方案四：mysqldump 導出導入 (邏輯備份、跨版本/跨實例/結構清理首選)

優勢：跨版本 (5.7→8.0)、跨引擎 (MyISAM→InnoDB)、跨實例/雲遷移、可編輯 SQL 清理垃圾索引/調整字符集。
劣勢：大庫耗時長 (受限單線程)、導入需重建索引 (二級索引逐行插入)、需雙倍磁盤空間存放 .sql。
加速變體：mydumper/myloader 多線程並行導出導入 (10x 加速)。


方案五：Shell/Python 自動化腳本 (批量庫遷移、CI/CD 集成、錯誤處理可控)
#!/bin/bash
# rename_db.sh old_db new_db
MYSQL="mysql -u root -p'pwd' -h localhost"
OLD=$1; NEW=$2
$MYSQL -e "CREATE DATABASE \`$NEW\`;"
TABLES=$($MYSQL -N -e "SELECT TABLE_NAME FROM information_schema.TABLES WHERE TABLE_SCHEMA='$OLD'")
for T in $TABLES; do
    $MYSQL -e "RENAME TABLE \`$OLD\`.\`$T\` TO \`$NEW\`.\`$T\`;" || { echo "FAIL $T"; exit 1; }
done
$MYSQL -e "DROP DATABASE \`$OLD\`;"
echo "SUCCESS: $OLD -> $NEW"

優勢：方案三的工程化封裝、支援批量 (迴圈調用)、錯誤即停、可集成 Ansible/Jenkins/GitLab CI、日志審計完整。
進階功能：並發 RENAME TABLE (分組並行)、預檢查 (外鍵/視圖/權限)、回滾預案 (重命名回滾)。


五大方案綜合對比表


維度
方案一 RENAME DB
方案二 目錄重命名
方案三 RENAME TABLE
方案四 mysqldump
方案五 Shell 自動化


速度
極快
極快
⚡ 秒級
🐢 分~時級
⚡ 秒~分級
InnoDB 支援
✗ 損壞
✗ 不支援
✓ 完美
✓ 重建
✓ 完美
跨實例
✗
✗
✗
✓ 最佳
✗ (可擴展)
停機需求
無 (但危險)
✓ 全庫停機
極短 MDL 鎖
導入期間讀寫分離
極短 MDL 鎖
元數據完整性
✗ 丟失
✗ 不更新
✓ 自動維護
✓ 重建
✓ 自動維護
風險等級
☠️ 極高
🔴 高
🟢 低
🟡 中 (導入失敗)
🟢 低 (可控)
推薦場景
無
純 MyISAM 唯讀
同實例重命名首選
跨版本/跨雲/結構重組
批量運維/自動化流水線



關鍵後續動作清單 (方案三/五必做)

視圖/存儲過程/觸發器/事件：mysqldump --no-data --routines --triggers --events old_db 導出定義 → sed 's/old_db/new_db/g' → 導入新庫。
權限遷移：SELECT CONCAT('GRANT ', PRIVILEGE_TYPE, ' ON new_db.* TO ', USER, HOST, ';') FROM information_schema.SCHEMA_PRIVILEGES WHERE TABLE_SCHEMA='old_db'; 批量生成 GRANT 語句。
應用配置熱更：藍綠部署 / 配置中心動態推送 / DNS 切換，避免硬編碼庫名重啟應用。
監控驗證：SHOW TABLES FROM new_db、抽樣 CHECKSUM TABLE、業務煙霧測試。


總結
MySQL 重命名資料庫，**同實例首選方案三 (RENAME TABLE) + 方案五 (自動化腳本)**，秒級完成、零數據拷貝、風險可控；**跨實例/版本/雲遷移首選方案四 (mysqldump/mydumper)**，通用性最強。方案一、二 已進入歷史垃圾箱，嚴禁生產踩坑。建立「備份→預檢→腳本→低峰執行→驗證→切換→觀察→清理」標準化 SOP，讓庫名變更成為常規無感運維動作。