MySQL 亂碼終極指南：從字符集流轉機制到抓包實戰的完整避坑地圖

核心認知：亂碼 = 編碼轉換錯誤

**傳輸不轉碼、存儲不轉碼、只有「輸入→連接→存儲」與「存儲→結果集→顯示」兩次轉碼會產生亂碼。** 只要全鏈路編碼一致，亂碼必不存在。

MySQL 字符集處理流程圖解

【寫入流程】
Client(character_set_client) 
  → 轉換 → connection(character_set_connection)  -- 第1次轉換
  → 傳輸（不轉碼）
  → Server: 按列字符集再轉換  -- 第2次轉換
  → 存儲（不轉碼）

【讀取流程】
存儲 
  → Server: 按 character_set_results 轉換  -- 逆向第2次
  → 傳輸（不轉碼）
  → Client: 按 character_set_client 轉換  -- 逆向第1次
  → 顯示（這裡看到亂碼）

關鍵變量速查

一條神奇命令：SET NAMES utf8mb4

SET NAMES utf8mb4;
-- 等價於同時設置：
SET character_set_client = utf8mb4;
SET character_set_connection = utf8mb4;
SET character_set_results = utf8mb4;

最佳實踐： 連接建立後**第一條語句**執行此命令，或在連接池/驅動配置中指定 characterEncoding=utf8mb4。

抓包實戰：latin1 vs utf8 為什麼都能「顯示正常」卻實則不同？

環境：Client/Connection/Results = latin1，Database/Server = utf8。插入「你」(UTF-8: E4 BD A0)。

現象 1：latin1 發送包 = 正確 UTF-8 字節

原因：客戶端編輯器是 UTF-8，latin1 單字節直通，字節內容不變（E4 BD A0），MySQL 以為是 3 個 latin1 字符。

現象 2：latin1 接收包 = 正確 UTF-8 字節

原因：Server 將列內容（實際存儲的 C3 A4 C2 BD C2 A0，即 UTF-8 字節被 latin1 解讀後的字符）按 latin1 輸出，恰好還原為 E4 BD A0。

現象 3：latin1 顯示正常

原因：終端 是 UTF-8，收到 E4 BD A0 直接渲染「你」。**這是「雙重錯誤抵消」的偽正常！** 數據庫實際存儲的是亂碼字符（6 字節），非真正 UTF-8（3 字節）。

現象 4：utf8 連接下接收/顯示反而亂碼

原因：連接/庫編碼一致，無轉換，直接輸出存儲的 C3 A4 C2 BD C2 A0，終端按 UTF-8 解析為 2 個雜字符。**這才是真實存儲狀態的忠實反映。**

避坑黃金法則

1. 全鏈路統一 utf8mb4：Server/Database/Table/Column/Connection/Client/Terminal
2. 連接建立即執行 SET NAMES utf8mb4
3. 驅動配置顯式指定編碼：JDBC characterEncoding=utf8mb4、PHP PDO charset=utf8mb4、Python charset='utf8mb4'
4. 表結構定義顯式字符集：CREATE TABLE ... CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci
5. 拒絕 latin1/utf8 混用：遷移歷史庫用 pt-online-schema-change 無鎖轉碼

排查清單（遇到亂碼按順序查）

1. SHOW VARIABLES LIKE 'character_set_%'; 確認 6 大變量
2. SELECT HEX(col), col FROM tbl LIMIT 1; 看實際存儲字節
3. 抓包/驅動日志確認發送/接收字節
4. 終端/瀏覽器編碼設置
5. 應用代碼中是否手動 SET NAMES 或驅動配置

總結

MySQL 亂碼本質是**編碼鏈路不一致導致的錯誤轉換**。**統一 utf8mb4 + 連接初始化 SET NAMES + 驅動顯式配置 + 顯式建表字符集**，從架構層面根治，不再靠運氣。