MySQL 中文亂碼問題的核心成因與解決思路

MySQL 導入數據時數字正常但中文顯示亂碼，本質上是字符編碼不一致導致的。解決此類問題的核心原則是：客戶端、連接層、服務端、數據表、數據庫五層編碼必須完全統一。本文將從腳本語句、框架配置、服務端配置、應用層代碼四個維度，系統梳理亂碼排查與修復方案。

一、 SQL 腳本導入階段的編碼控制

1. 導入前強制指定客戶端字符集

在執行導入腳本前，務必先執行：

SET NAMES gbk;

或根據實際文件編碼指定 utf8/utf8mb4。這能確保客戶端發送的 SQL 語句按正確編碼被服務端解析。

2. 表字段編碼修改

若表結構編碼與數據不符，需修改字段級編碼：

ALTER TABLE `table_name` MODIFY `column_name` VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

注意：某些客戶端工具（如 Navicat、DataGrip）執行導入腳本時不會報錯，但命令行客戶端可能報錯。建議統一使用專業 GUI 工具操作。

二、 MyBatis / Spring Boot 等框架層配置

1. Mapper XML 中的連接參數

在 MyBatis 的 mapper 配置或 Spring Boot application.yml 中，JDBC URL 必須顯式指定編碼：

jdbc:mysql://host:3306/db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai

2. JUnit 測試中文讀取異常

測試類中若出現中文亂碼，檢查 JVM 啟動參數或 IDE 運行配置的編碼設置：

-Dfile.encoding=UTF-8

三、 MySQL 服務端核心配置文件（my.ini / my.cnf）修改

這是徹底解決亂碼的關鍵。打開安裝目錄下的 my.ini（Windows）或 /etc/my.cnf（Linux），在 [mysqld]、[client]、[mysql] 三個區塊分別設置：

[client]
default-character-set=utf8mb4

[mysqld]
character-set-server = utf8mb4
collation-server = utf8mb4_general_ci
init_connect='SET NAMES utf8mb4'

[mysql]
default-character-set=utf8mb4

關鍵點：必須同時修改客戶端與服務端配置，且推薦使用 utf8mb4 而非舊版 utf8，以完整支持 Emoji 及生僻字。

修改保存後，必須重啟 MySQL 服務 使配置生效：

• Windows: net stop mysql && net start mysql
• Linux: systemctl restart mysqld 或 service mysql restart

四、 PHP / Java 等應用層代碼修復

1. PHP 連接階段設置字符集

在 mysqli_connect() 或 PDO 實例化後立即執行：

$mysqli->set_charset("utf8mb4");
// 或 PDO
$pdo = new PDO($dsn, $user, $pass, [PDO::MYSQL_ATTR_INIT_COMMAND => 'SET NAMES utf8mb4']);

2. 歷史項目編碼不匹配的緊急處理

若數據庫為 UTF-8 但頁面聲明 GB2312，查詢前執行：

mysqli_query($link, "SET NAMES GBK");

但強烈建議全站統一遷移至 UTF-8/utf8mb4，避免後續維護陷阱。

五、 驗證與排查清單

1. SHOW VARIABLES LIKE 'character%'; 確認所有字符集變量為 utf8mb4
2. SHOW CREATE TABLE table_name; 檢查表/字段級編碼
3. 插入測試數據：INSERT INTO t(c) VALUES('測試😀'); 驗證存取正常
4. 檢查應用日誌中是否仍有 Incorrect string value 報錯

總結

MySQL 中文亂碼 90% 以上源於編碼鏈路不一致。採用 utf8mb4 全鏈路統一、配置文件落地、重啟服務生效 三步走策略，可徹底根治。避免在代碼層面用 SET NAMES 臨時修補，應從架構層面統一標準。