MySQL 字符集設置全攻略：變量解讀、亂碼成因、編碼轉換實戰與最佳實踐
字符集問題是 MySQL 亂碼、數據截斷的首因。本文系統講解 4 個核心字符集變量交互流程、亂碼/丟失數據成因、動態/永久設置方法、存量庫表編碼轉換標準流程。
核心變量與轉換流程
SHOW VARIABLES LIKE 'character%';
關鍵變量：
character_set_client：客戶端發送編碼，告訴轉換器「我發什麼編碼」。character_set_connection：轉換器將客戶端數據轉為此編碼，再交給 Server。character_set_server：Server 存儲編碼（建庫表默認）。character_set_results：查詢結果輸出編碼。
流程：Client → (client編碼) → 轉換器 → (connection編碼) → Server (server編碼存儲) → 轉換器 → (results編碼) → Client
亂碼與數據丟失成因分析
| 現象 | 原因 | 對策 |
|---|
| 亂碼 | client 與實際不符（如 Windows CMD 默認 GBK，卻設 utf8） | 設置 client = 實際終端編碼 |
| 亂碼 | results 與前端頁面編碼不符 | 設置 results = 頁面編碼 |
| 數據丟失/截斷 | connection 編碼 < server 編碼（如 client=utf8, connection=gbk） | connection ≥ server，建議均用 utf8 |
動態設置與永久配置
會話級：SET NAMES utf8（等同於同時設 client、connection、results）。
永久生效：my.cnf：
[client]
default-character-set=utf8
[mysqld]
character-set-server=utf8
collation-server=utf8_general_ci
存量數據庫編碼轉換標準流程（latin1 → gbk/utf8）
- 導出表結構：
mysqldump -uroot -p --default-character-set=gbk -d DB_NAME > createtable.sql（-d 僅結構，指定連接編碼為目標編碼）。
- 修改 SQL 文件：將
CHARSET=latin1 替換為 CHARSET=gbk。
- 導出純數據：
mysqldump -uroot -p --quick --no-create-info --extended-insert --default-character-set=latin1 DB_NAME > data.sql（按原編碼導出，保證中文可見）。
- 修改數據文件：將
SET NAMES latin1 改為 SET NAMES gbk。
- 創建新庫：
CREATE DATABASE DB_NAME DEFAULT CHARSET gbk;
- 導入結構：
mysql -uroot -p DB_NAME < createtable.sql
- 導入數據：
mysql -uroot -p DB_NAME < data.sql
參數說明：--quick 流式導出大表；--extended-insert 多值 INSERT 加速導入；--no-create-info 不含建表語句。
- 上一篇文章： Percona XtraBackup 實戰教程：全量備份、增量備份、還原恢復與內存優化參數
- 下一篇文章： CentOS 編譯安裝 MySQL 5.6 完整教程：依賴解決、CMake 參數詳解、Yum 源配置與庫文件導出
Copyright ©
程式碼之家 All Rights Reserved
