MySQL SET NAMES utf8 深度解析：亂碼根因與字符集流轉機制

現象還原

執行 SET NAMES utf8 前後，三個關鍵會話變量發生變化：

官方文檔：Connection Character Sets and Collations

字符集流轉全鏈路

客戶端應用
    │ 發送 SQL (bytes) ──► character_set_client
    ▼
MySQL Server
    │ 解析/執行 ──► character_set_connection
    │ 內部操作 (存儲引擎使用 column charset)
    │ 結果集編碼轉換 ──► character_set_results
    ▼
客戶端應用
    │ 接收結果 (bytes) ──► 按 character_set_results 解碼

SET NAMES 等價操作

SET NAMES 'utf8'
≡
SET character_set_client = utf8;
SET character_set_connection = utf8;
SET character_set_results = utf8;

此外，SET NAMES utf8mb4 會同步設置 collation_connection = utf8mb4_general_ci（或默認校對規則）。

亂碼經典場景拆解

場景 1：客戶端編碼與表列編碼不一致

• 表列 CHARSET=gbk，客戶端發送 UTF-8 字節，未執行 SET NAMES utf8，服務端按 latin1 或 gbk 解析 → 存入錯誤字節 → 讀出亂碼。
• 修正：連接建立後立即 SET NAMES utf8mb4，或 JDBC URL 加 characterEncoding=utf8mb4。

場景 2：雙重編碼

• 應用層已將字符串按 UTF-8 編碼為 byte[]，再以 ISO-8859-1 發送；服務端按 character_set_client=utf8 解析 → 字節被二次解讀 → 存入錯誤數據。
• 原則：**應用層字符串保持 Unicode，交由驅動按連接字符集編碼**，勿手動編碼。

場景 3：結果集編碼錯配

• 數據庫存儲正確，但 character_set_results=latin1，客戶端按 UTF-8 解碼 → 亂碼。
• 修正：SET NAMES utf8mb4 同步設置 results。

最佳實踐清單

1. 統一字符集：庫、表、列、連接全鏈路使用 utf8mb4（支持 Emoji，utf8 實為 utf8mb3）。
2. 連接池初始化：HikariCP / Druid 配置 connectionInitSqls: "SET NAMES utf8mb4"。
3. JDBC URL 顯式指定：

   jdbc:mysql://host:3306/db?characterEncoding=utf8mb4&useSSL=false&serverTimezone=Asia/Shanghai

4. 避免 SET NAMES 手動調用：依賴驅動自動協商，減少會話狀態不一致風險。
5. 排查利器：

   SHOW VARIABLES LIKE 'character_set_%';
   SHOW VARIABLES LIKE 'collation_%';
   SELECT HEX(column) FROM table WHERE ...;  -- 查看真實存儲字節

進階：collation 衝突

即使字符集一致，校對規則不同也會導致比較、排序、分組異常。例如 utf8mb4_general_ci vs utf8mb4_unicode_ci 對德語 ß、拼音排序規則不同。建議全鏈路統一 utf8mb4_0900_ai_ci（MySQL 8.0 默認，基於 Unicode 9.0，語感排序、不區分重音、大小寫）。

總結

SET NAMES utf8 本質是同步會話層三個字符集變量，確保「客戶端發什麼、服務端懂什麼、返回什麼、客戶端能識別」。徹底解決亂碼，關鍵在於**全鏈路字符集統一、驅動層自動協商、避免應用層干預編碼**。