MySQL 4.1 字符集遷移實戰：從 GB2312 平滑過渡到 UTF-8

遷移背景與挑戰

MySQL 4.1 引入完整字符集支持，但歷史數據多為 GB2312/GBK 編碼。直接升級會導致亂碼、排序錯誤、應用報錯。本文提供經驗證的「導出→轉碼→導入→驗證」四步法，確保數據零損失、業務零停機。

四步遷移法

步驟 1：導出數據與結構

# 單庫導出（含 DROP TABLE、擴展 INSERT、不鎖表）
mysqldump -u root -p --default-character-set=gbk \
  --add-drop-table --extended-insert --single-transaction \
  mydb > mydb_gbk.sql

# 僅導出結構（用於對比）
mysqldump -u root -p --no-data --default-character-set=gbk mydb > mydb_struct.sql

關鍵參數：--default-character-set=gbk 強制以 GBK 讀取，避免 mysqldump 按 latin1 解析導致雙重編碼。

步驟 2：文件級編碼轉換

# 方法 A：iconv（Linux/Mac 推薦）
iconv -f gbk -t utf-8 mydb_gbk.sql > mydb_utf8.sql

# 方法 B：EmEditor / Notepad++（Windows）
# 打開文件 → 「另存為編碼」選 UTF-8 **無 BOM**

# 關鍵替換（使用編輯器全局替換）
sed -i 's/DEFAULT CHARSET=gbk/DEFAULT CHARSET=utf8/g' mydb_utf8.sql
sed -i 's/CHARSET=gbk/CHARSET=utf8/g' mydb_utf8.sql
sed -i 's/collate gbk_/collate utf8_general_ci/g' mydb_utf8.sql

# 文件頭插入會話字符集聲明
sed -i '1i SET NAMES utf8;' mydb_utf8.sql

避坑指南：

• ❌ 絕對不要保留 UTF-8 BOM（EF BB BF），MySQL 客戶端會報 ERROR 1064。
• ❌ 不要用 utf8mb4 替換 utf8（除非確認表無長度限制問題），4.1 版本僅支持 utf8（即 utf8mb3）。
• ✅ 保留 /*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */ 等版本註釋，向後兼容。

步驟 3：創建新庫並導入

# 登入 MySQL 創建新庫（指定默認字符集）
mysql -u root -p -e "CREATE DATABASE mydb_utf8 DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;"

# 導入（若報 max_allowed_packet 錯誤見下文）
mysql -u root -p --default-character-set=utf8 mydb_utf8 < mydb_utf8.sql

步驟 4：大包錯誤應對

錯誤：Got a packet bigger than 'max_allowed_packet' bytes

# 臨時調大（立即生效，無需重啟）
mysql -u root -p -e "SET GLOBAL max_allowed_packet = 1073741824;"  -- 1GB

# 永久生效（my.cnf / my.ini）
[mysqld]
max_allowed_packet = 1G

# 導入完成後恢復默認值（如 64M）

應用層配置同步

驗證清單

1. SHOW VARIABLES LIKE 'character_set_%'; 確認 client/connection/results/database 均為 utf8。
2. 抽樣查詢中文數據：SELECT col, HEX(col) FROM tbl LIMIT 10; 檢查十六進制是否符合 UTF-8 編碼規律（中文 3 字節）。
3. 應用端端到端測試：寫入→讀取→展示，含特殊字符（Emoji、生僻字）。
4. 對比舊新庫行數、校驗和：CHECKSUM TABLE tbl;。

總結

字符集遷移核心在於「導出時正確聲明源編碼，文件轉碼徹底，導入時正確聲明目標編碼，應用層同步配置」。遵循本文四步法並逐項驗證，可將遷移風險降至最低。生產環境建議先在備庫演練，確認無誤後再切換主庫。