深度解析 MySQL 字符集轉換機制：從 client 到 server 的完整流程與亂碼根因

關鍵系統變量

字符集轉換三階段

1. 請求入站：client → connection（若不一致則轉換）
2. 內部操作：connection → 列/表/庫/Server 默認（按優先級落地存儲）
3. 結果出站：內部編碼 → results（返回客戶端）

兩大經典亂碼場景

場景 A：寫入未設連接編碼，讀取時設了

-- 寫入時：client=latin1, connection=latin1, results=latin1
-- 實際數據為 UTF-8（3 字節/中文）
-- 經歷：latin1 → latin1 → utf8 存儲 → 每個中文變 6 字節（雙重編碼）

-- 讀取時：client=utf8, connection=utf8, results=utf8
-- 經歷：utf8 → utf8 返回 → 6 字節原樣輸出 → 客戶端按 UTF-8 解碼 → 亂碼

場景 B：寫入設了 UTF-8 連接，但表為 latin1

-- 寫入：client=utf8, connection=utf8, results=utf8
-- 經歷：utf8 → utf8 → latin1 存儲 → 超出 latin1 範圍字符變 ? (0x3F) → 永久損壞

-- 後續任何連接讀取均無法恢復原文

Introducer 語法：強制指定字面值編碼

SELECT _utf8mb4 '中文' COLLATE utf8mb4_unicode_ci;
INSERT INTO t(col) VALUES (_latin1 'abc');

帶 Introducer 的字面值**跳過連接層轉換**，直接按指定編碼進入內部處理。

診斷工具箱

SHOW VARIABLES LIKE 'character_set_%';
SHOW VARIABLES LIKE 'collation_%';
SELECT HEX(col), LENGTH(col), CHAR_LENGTH(col) FROM t WHERE id=1;
SELECT CHARSET(col), COLLATION(col) FROM t LIMIT 1;

最佳實踐清單

1. 📌 **庫/表/欄位顯式指定 CHARSET**，不依賴默認值（升級時默認值可能變更）。
2. 📌 **連接層統一 utf8mb4**：驅動層設定（JDBC characterEncoding、PHP mysqli_set_charset、Python charset='utf8mb4'），免去 SET NAMES 額外圍觀。
3. 📌 **長連接重連後必須重置字符集**（驅動自動重連不保證重置）。
4. 📌 my.cnf 的 default-character-set **僅影響 mysql 命令列客戶端**，不影響 libmysqlclient 應用。
5. 📌 SQL 函數操作（UPPER()、SUBSTRING() 等）在**內部操作編碼**下執行，不受連接編碼影響。
6. 📌 字面值比較注意 Introducer 與連接編碼交互，必要時顯式 COLLATE。

編碼容量對照（Maxlen）

⚠️ **轉換時若目標 Maxlen < 來源 Maxlen，超出範圍字符將截斷或變 ?，造成不可逆資料損失。**