.jpg)
mysql分區(qū)表出現(xiàn)中文亂碼的根本原因是字符集配置不當(dāng)，而非分區(qū)本身導(dǎo)致。1. 首先要確保數(shù)據(jù)庫、表和字段的字符集為utf8mb4，建庫建表時(shí)顯式指定，并可通過alter語句修改已有對象的字符集，同時(shí)注意檢查字段級別的字符集是否同步更新。2. 連接層需統(tǒng)一設(shè)置為utf8mb4，通過set names命令或在程序連接參數(shù)中指定charset，確保傳輸過程不出現(xiàn)編碼轉(zhuǎn)換問題。3. 分區(qū)鍵盡量避免使用中文字段，推薦使用varchar或text類型存儲中文，并注意分區(qū)策略對性能和排序的影響。4. 導(dǎo)出導(dǎo)入數(shù)據(jù)時(shí)也必須指定–default-character-set=utf8mb4參數(shù)，防止因默認(rèn)字符集不同導(dǎo)致編碼轉(zhuǎn)換錯(cuò)誤。只要從創(chuàng)建數(shù)據(jù)庫開始，每一步都保持字符集一致，就能有效避免分區(qū)表中的中文亂碼問題。
mysql分區(qū)表出現(xiàn)中文亂碼，其實(shí)跟分區(qū)本身關(guān)系不大，更多是字符集配置的問題。不過在實(shí)際使用中，尤其是在處理分區(qū)表時(shí)，如果前期配置不當(dāng)，確實(shí)容易遇到中文顯示異常的情況。下面我結(jié)合常見的幾種場景，說說怎么排查和處理這類問題。
1. 檢查數(shù)據(jù)庫、表、字段的字符集設(shè)置
這是最基礎(chǔ)也是最容易出錯(cuò)的地方。如果你的數(shù)據(jù)庫、表或者字段的字符集不是 utf8mb4，那插入中文就很可能會出問題。
- 數(shù)據(jù)庫創(chuàng)建時(shí)指定字符集：
CREATE DATABASE mydb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
- 表創(chuàng)建時(shí)也要指定字符集：
CREATE TABLE mytable ( id INT PRIMARY KEY ) PARTITION BY RANGE (id) (...) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
- 如果已經(jīng)存在表，可以用如下語句修改字符集：
ALTER DATABASE mydb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE mytable CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
注意：修改后最好檢查一下字段級別的字符集是否也同步了，有時(shí)候單獨(dú)字段可能還是舊的字符集（比如 latin1）。
2. 連接層字符集設(shè)置要一致
很多情況下，數(shù)據(jù)本身沒問題，但連接的時(shí)候沒設(shè)置好字符集，也會導(dǎo)致讀寫中文時(shí)亂碼。
- 在客戶端連接 MySQL 的時(shí)候，執(zhí)行：
SET NAMES 'utf8mb4';
這條命令相當(dāng)于同時(shí)設(shè)置了 character_set_client, character_set_connection, character_set_results 三個(gè)參數(shù)為 utf8mb4，確保傳輸過程不亂碼。
import pymysql conn = pymysql.connect( host='localhost', user='root', password='xxx', database='mydb', charset='utf8mb4' )
3. 分區(qū)鍵和中文字段的關(guān)系（注意字段類型）
雖然分區(qū)鍵本身通常不會直接存中文，但如果分區(qū)策略涉及到某些字段（比如按時(shí)間分區(qū)），而你又在這個(gè)表里存了中文，就需要注意字段類型。
- 中文推薦使用 VARCHAR 或 TEXT 類型，并且字符集一定要是 utf8mb4。
- 不建議把中文字段作為分區(qū)鍵，因?yàn)榉謪^(qū)鍵對性能有要求，而且中文排序、比較邏輯復(fù)雜，容易引發(fā)不可預(yù)料的問題。
舉個(gè)例子，下面這個(gè)建表語句雖然語法上沒錯(cuò)，但實(shí)際使用中會很麻煩：
CREATE TABLE logs ( log_id INT, content TEXT ) PARTITION BY HASH (content) PARTITIONS 4;
這種按中文內(nèi)容做哈希分區(qū)的做法，不僅效率低，還可能因字符集處理差異導(dǎo)致數(shù)據(jù)錯(cuò)亂。
4. 特殊情況：導(dǎo)出導(dǎo)入導(dǎo)致的編碼轉(zhuǎn)換問題
有些時(shí)候，你在本地開發(fā)環(huán)境測試沒問題，但上線部署之后出現(xiàn)亂碼，可能是導(dǎo)出導(dǎo)入 SQL 文件時(shí)沒指定編碼。
- 導(dǎo)出時(shí)加字符集參數(shù)：
mysqldump -u root -p --default-character-set=utf8mb4 mydb > backup.sql
- 導(dǎo)入時(shí)同樣指定：
mysql -u root -p --default-character-set=utf8mb4 mydb < backup.sql
如果不加這個(gè)參數(shù)，默認(rèn)可能會用 latin1 去解析文件，結(jié)果就是一堆問號或亂碼字符。
基本上就這些。分區(qū)表本身不會引起中文亂碼，但因?yàn)樗婕岸鄠€(gè)子表、分片策略，一旦某個(gè)環(huán)節(jié)字符集不統(tǒng)一，排查起來更麻煩。所以從創(chuàng)建數(shù)據(jù)庫開始，每一步都保持一致性很重要。
.png)
