MySQL 4.0 升級 4.1 中文亂碼終極解決方案

升級遷移中的字符集陷阱

MySQL 4.0 無字符集概念，4.1+ 引入多字符集支持。直接導入 4.0 導出的數據到 4.1，中文極易亂碼。本文提供經實戰驗證的兩種遷移方案。

方案一：BINARY 中轉法（推薦）

1. 將目標 MySQL 4.1 實例默認字符集設置為 gb2312（或 utf8）
2. 打開導出的 SQL 文件，修改所有 CREATE TABLE 語句：
   將字段類型 CHAR → BINARY，VARCHAR → VARBINARY
   示例：CREATE TABLE t (c VARCHAR(50)) CHARACTER SET BINARY;
3. 導入數據至新庫，此時中文以二進制形式存儲，不發生編碼轉換
4. 導入後執行 ALTER TABLE t MODIFY c VARCHAR(50) CHARACTER SET gb2312; 恢復原類型並指定字符集

方案二：逐字段轉換法（表少時適用）

若表較少，可導入後逐個字段執行：

ALTER TABLE t CHANGE c c VARCHAR(50) CHARACTER SET gb2312;

避免一次性修改大量表導致鎖表過久影響性能。

核心原理

MySQL 4.1 導入時會根據目標表字符集對數據進行編碼轉換。通過先聲明為 BINARY，MySQL 視為無編碼二進制數據，直接存儲原始字節；後再指定正確字符集，實現無損遷移。

避坑指南

• 導出前確認 4.0 數據實際編碼（通常為 gb2312/latin1）
• 大數據量建議用 mysqldump --default-character-set=latin1 導出
• 導入後務必用 SELECT HEX(column) 驗證字節一致性