MySQL 亂碼問題根因分析與系統級排查方法論

案例背景

功能：Dom4J 讀 XML → Spring/Hibernate 寫 MySQL（多表、事務）。
現象：寫入中段報錯「記錄不唯一」，實為外鍵關聯失敗，數據庫中外鍵值顯示亂碼。

排查全過程復盤

階段一：定位亂碼產生環節

• 斷點調試：Java 內存中字符串正常
• 結論：非讀取/業務邏輯問題，屬於持久化/數據庫層

階段二：數據庫編碼配置排查

• 修改連接串 characterEncoding=utf8
• 修改庫/表默認字符集
• 現象：亂碼形式變了（全 '?' → 亂七八糟文字），說明配置生效但仍未匹配

階段三：命令行顯示陷阱

• 第三方客戶端（Navicat/SQLyog）顯示正常
• CMD mysql 客戶端顯示亂碼
• 執行 SET NAMES gbk; 後 CMD 顯示正常
• 真相：數據庫中數據一直正常，是 CMD 客戶端編碼默認 GBK 導致顯示異常

編碼全鏈路檢查清單

方法論總結：從「魚」到「漁」

1. 完整跑通流程：調試必須讓程序執行完，還原完整上下文，而非只盯著報錯行
2. 全局觀控制變量：從源頭到終端，每個編碼環節都是控制變量，缺一不可
3. 工具驗證分層：用圖形化客戶端排除數據層問題，再排查顯示層
4. 記錄配置快照：每次修改記錄 before/after，避免反覆試錯

終極建議

新專案統一 utf8mb4 全鏈路：庫、表、列、連接、文件、客戶端。歷史項目遷移需謹慎規劃，建議雙寫驗證後再切換。