MySQL 跨字符集主備校驗亂碼問題：連接層字符集統一與修復策略最佳實踐

場景還原

• 主庫：CHARACTER SET = utf8mb4
• 備庫：CHARACTER SET = gbk
• 校驗程序：分別建立連接查詢，逐字段 strcasecmp 比對
• 現象：明明相同漢字，程序判定不一致

根因：連接字符集不一致導致字節流不同

主庫連接字符集 = utf8  → 返回 UTF-8 編碼字節流 (如 '中' = E4 B8 AD)
備庫連接字符集 = gbk  → 返回 GBK 編碼字節流   (如 '中' = D6 D0)
程序直接比較字節流 → 不相等 → 誤報不一致

字符集轉換流程圖解

客戶端請求 → character_set_client → character_set_connection → 數據庫內部編碼
數據庫響應 → 內部編碼 → character_set_connection → character_set_results → 客戶端

關鍵參數：

• character_set_client：客戶端發送數據編碼
• character_set_connection：連接層處理編碼
• character_set_results：結果集返回編碼
• character_set_database：當前庫默認編碼
• character_set_system：系統元數據編碼 (固定 utf8)

三種連接設置方案對比

核心結論

跨字符集校驗/修復，必須統一連接字符集為「編碼範圍最大」的那一方（utf8mb4 > gbk > gb2312 > latin1）。

• 方案 3 雖導致客戶端顯示亂碼，但不影響程序內部比較與修復邏輯。
• 修復 SQL 示例：

-- 統一 utf8 連接後，備庫讀取的值已轉為 UTF-8 字節流
UPDATE slave_table 
SET col = master_value 
WHERE pk = ? AND col = slave_value;  -- slave_value 為 UTF-8 編碼，精確匹配

若用方案 2 (統一 gbk)：

-- 主庫 utf8 數據轉 gbk 時，Emoji/生僻字丟失 → slave_value 已殘缺
UPDATE slave_table SET col = master_value WHERE pk = ? AND col = slave_value;
-- WHERE 條件不匹配 (slave_value 丟字) → 0 rows affected → 修復失敗

實施標準化配置

# 校驗/修復程序連接參數 (統一)
charset = 'utf8mb4'        # 或 utf8
use_unicode = True
# 禁用服務端字符集握手 (強制以客戶端為準)
# MySQL 連接串
jdbc:mysql://host:3306/db?characterEncoding=utf8mb4&connectionCollation=utf8mb4_general_ci

# 或代碼中顯式設置
SET NAMES utf8mb4;  -- 等價於
SET character_set_client = utf8mb4;
SET character_set_connection = utf8mb4;
SET character_set_results = utf8mb4;

生產環境字符集治理建議

1. 全鏈路統一 utf8mb4：新建庫表、連接池、應用框架、客戶端工具全部強制 utf8mb4。
2. 歷史 gbk 庫遷移：ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4，驗證無數據截斷/丟失。
3. 校驗工具內建轉碼：若無法統一連接字符集，程序層引入 iconv/mb_convert_encoding 將兩邊統一到 UTF-8 後再比較。
4. 監控字符集異常：定期掃描 SHOW VARIABLES LIKE 'character_set%'，發現非 utf8mb4 告警。