MySQL 數據移植中的亂碼問題

MySQL 數據移植中的亂碼問題

本文原內容極少，僅有標題。MySQL 數據移植（遷移/導入導出）過程中常見的亂碼問題，通常由字符集不一致引起。核心排查方向如下：

• 源庫與目標庫字符集不匹配：如源表為 gbk，目標表為 latin1 或 utf8，導入後顯示問號或亂碼。
• 連接層字符集未指定：JDBC URL 缺少 characterEncoding=utf8、useUnicode=true 參數；或客戶端工具（Navicat、Workbench 等）編碼設置錯誤。
• 導出/導入工具默認編碼差異：mysqldump 未加 --default-character-set，或 SQL 文件本身編碼與執行環境不符。
• 表/列級字符集覆蓋：表默認 utf8 但某列指定 gbk，遷移時需逐列對齊。

通用解決步驟：

1. 確認源庫表結構字符集：SHOW CREATE TABLE tbl_name;
2. 目標庫建表時顯式指定相同字符集：CREATE TABLE ... CHARSET=gbk;
3. 導出時指定編碼：mysqldump --default-character-set=gbk ...
4. 導入前設置會話字符集：SET NAMES gbk; 或在連接串中配置。
5. 驗證數據：SELECT HEX(col), col FROM tbl LIMIT 1; 對比十六進制碼位。

原則：全鏈路字符集保持一致（源表 → 導出文件 → 連接會話 → 目標表）。