MySQL 字符集亂碼根因分析：只需統一「客戶端字符集」即可避免亂碼

MySQL 涉及多層字符集：character_set_server（服務端）、character_set_database（資料庫）、character_set_client（客戶端）、character_set_connection、character_set_results。實測發現：**只要寫入與讀取時的客戶端字符集一致，資料庫字符集設定不影響正確性**（僅影響轉換效能與遷移相容性）。

核心結論

寫入時 MySQL 將 client charset 轉為 database charset 存盤；
讀取時將 database charset 轉回 client charset 傳回。
若兩次操作的 client charset 相同，雙向轉換抵消，資料完好無損。

客戶端字符集設定方式（依連線類型）

常用字符集檢視指令

-- 1. 伺服器/資料庫/客戶端字符集
SHOW VARIABLES LIKE 'character_set_%';

-- 2. 資料表字符集
SHOW TABLE STATUS FROM db_name LIKE 'tbl_name';

-- 3. 欄位字符集
SHOW FULL COLUMNS FROM tbl_name;

-- 4. 支援的字符集清單
SHOW CHARACTER SET;

最佳實踐建議

1. 全鏈路統一：應用、連線池、GUI 工具、命令列、備份腳本全部指定相同字符集（推薦 utf8mb4）。
2. 資料庫/表/欄位同步：建庫建表時顯式指定 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci，避免隱式繼承造成不一致。
3. 避免雙重轉換：若客戶端與資料庫字符集一致，可省去轉換 CPU 開銷。
4. 遷移無痛：統一用 utf8mb4，未來遷移至 PostgreSQL、TiDB、OceanBase 等均無字符集障礙。

常見誤區

• 只改 my.ini [mysqld] default-character-set 卻未改應用連線字串 → 依然亂碼。
• 以為資料庫字符集決定一切 → 實際上客戶端字符集才是關鍵。
• 混用 utf8（MySQL 3 字節子集）與 utf8mb4 → 存 Emoji 截斷或報錯。