前言

一句話定調：新項目永遠選 utf8mb4 + utf8mb4_0900_ai_ci。
絕大多數(shù)“中文亂碼/emoji 報錯/唯一索引異常/大小寫不一致”的鍋，最后都能追到：字符集/排序規(guī)則沒統(tǒng)一。

0. 先搞清兩個概念：字符集 vs 排序規(guī)則

• 字符集（Character Set）：決定“字符怎么編碼存儲”（能不能存 emoji、本質占多少字節(jié)）
• 排序規(guī)則（Collation）：決定“字符怎么比較/排序”（是否大小寫敏感、是否忽略重音、中文排序規(guī)則）

舉個最直觀的：

• utf8mb4 決定你能不能存 ??
• utf8mb4_0900_ai_ci 決定 'A' 是否等于 'a'、é 和 e 是否算相等、排序是否更準確

1. DEFAULT CHARACTER SET 是否必須寫？

1.1 結論（按場景給）

1.2 DataGrip 為什么默認不寫？

因為它遵循“不寫 = 用服務器默認”。
MySQL 8.x 常見默認：

• character_set_server = utf8mb4
• collation_server = utf8mb4_0900_ai_ci

因此下面兩句在“默認未被你改過”的前提下等價：

-- DataGrip 默認：不寫
CREATE DATABASE app_db;

-- 顯式寫：更可控
CREATE DATABASE app_db
  DEFAULT CHARACTER SET utf8mb4
  COLLATE utf8mb4_0900_ai_ci;

1.3 怎么確認你機器/線上到底默認是什么？

SHOW VARIABLES LIKE 'character_set_server';
SHOW VARIABLES LIKE 'collation_server';

SHOW VARIABLES LIKE 'character_set_%';
SHOW VARIABLES LIKE 'collation_%';

? 建議把“線上默認值截圖/記錄”寫進運維文檔，否則遲早有人踩坑。

2. utf8mb3 vs utf8mb4：別再被utf8這個名字騙了

2.1 核心結論

• ? utf8mb4 = 真正的 UTF-8（完整 Unicode，支持 emoji）
• ? utf8mb3（或 utf8）= MySQL 歷史遺留的 3 字節(jié) UTF-8，不完整

MySQL 里 utf8 實際上長期等價于 utf8mb3（只支持最多 3 字節(jié)），這就是最大誤導點。

2.2 對比表

2.3 最典型的報錯

-- 在 utf8mb3/utf8 表里插入 emoji 往往會失敗
INSERT INTO user(username) VALUES ('張三??');

常見錯誤類似：

• Incorrect string value: '\xF0\x9F...' for column ...

2.4 為什么“新項目用 utf8mb3 = 技術債”？

因為這不是“是否需要 emoji”的問題：

• 你永遠無法保證用戶輸入、第三方接口、運營文案、復制粘貼內容不出現(xiàn) 4 字節(jié)字符
• 一旦出現(xiàn)，輕則插入失敗，重則數(shù)據(jù)截斷、業(yè)務異常、日志污染

3. 排序規(guī)則（Collation）怎么選：0900_ai_ci vs unicode_ci vs bin

排序規(guī)則名字拆開看：

• utf8mb4_0900_ai_ci
  • 0900：Unicode 9.0
  • ai：accent-insensitive（忽略重音）
  • ci：case-insensitive（不區(qū)分大小寫）

3.1 常見三種排序規(guī)則的定位

A）utf8mb4_0900_ai_ci（MySQL 8.x 推薦默認）

? 適合：絕大多數(shù)業(yè)務表、用戶輸入、通用字符串
特點：

• Unicode 9.0，規(guī)則更新更全
• 比舊版 unicode_ci 更準確
• 性能通常更好（實現(xiàn)更現(xiàn)代）

B）utf8mb4_unicode_ci（兼容舊項目/5.7 常用）

? 適合：歷史系統(tǒng)已用該排序規(guī)則，或需兼容 MySQL 5.7
特點：

• 規(guī)則更舊（非 9.0）
• 通常也夠用，但不是最優(yōu)

C）utf8mb4_bin（嚴格區(qū)分大小寫/二進制比較）

? 適合：密碼 hash、token、大小寫敏感賬號、簽名、驗證碼、唯一標識
特點：

• A ≠ a
• 比較按字節(jié)序（“最嚴格”）

3.2 重點后綴：_ci / _cs / _bin

?? 業(yè)務最容易踩的坑：用戶名/郵箱用 _ci，你以為 Tom 和 tom 是兩個人，但數(shù)據(jù)庫認為相等，唯一索引直接沖突。

4. 實戰(zhàn)建議：怎么給“庫/表/字段”落地標準？

4.1 新項目（MySQL 8.x）標準建庫模板（推薦）

CREATE DATABASE app_db
  DEFAULT CHARACTER SET utf8mb4
  COLLATE utf8mb4_0900_ai_ci;

4.2 兼容 MySQL 5.7（或老項目遷移）模板

CREATE DATABASE app_db
  DEFAULT CHARACTER SET utf8mb4
  COLLATE utf8mb4_unicode_ci;

4.3 建表時建議也顯式寫（團隊協(xié)作更穩(wěn)）

CREATE TABLE user (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  username VARCHAR(50) NOT NULL
) ENGINE=InnoDB
  DEFAULT CHARSET=utf8mb4
  COLLATE=utf8mb4_0900_ai_ci;

4.4 字段級別什么時候需要單獨設置？

一般不需要，繼承庫/表的默認即可。

只有在“局部需要強規(guī)則”時才做字段級設置：

-- token/密鑰/大小寫敏感字段
token VARCHAR(64) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NOT NULL;

5. 常見坑位提醒（面試/線上事故高頻）

5.1 唯一索引長度問題（老版本）

• utf8mb4 下 VARCHAR(255) 最壞是 255 * 4 = 1020 bytes
• MySQL 5.6/早期 5.7 可能受限（767 bytes 等歷史限制）
• MySQL 8 大多無需擔心，但老環(huán)境可能要：
  • 改 VARCHAR(191)
  • 或用前綴索引

5.2 “同一庫里表的 collation 不一致”導致的隱蔽 bug

表現(xiàn)：

• join/union 報錯：Illegal mix of collations
• 比較結果異常、排序不一致
  解決：
• 統(tǒng)一庫 → 表 → 字段層級的默認值
• 遷移時用腳本批量檢查并修正

5.3 大小寫不敏感導致唯一索引誤傷

• utf8mb4_0900_ai_ci 下：Tom 和 tom 認為相等
• 如果賬號體系需要區(qū)分大小寫（少見，但存在），要用 _bin 或特定 _cs

6. 快速參考（直接貼到文檔里）

6.1 選型速查表

6.2 常用排查命令

-- 服務器默認
SHOW VARIABLES LIKE 'character_set_server';
SHOW VARIABLES LIKE 'collation_server';

-- 數(shù)據(jù)庫定義
SHOW CREATE DATABASE app_db;

-- 表定義
SHOW CREATE TABLE user;

-- 當前連接字符集（很重要，決定客戶端發(fā)給服務端怎么編碼）
SHOW VARIABLES LIKE 'character_set_client';
SHOW VARIABLES LIKE 'character_set_connection';
SHOW VARIABLES LIKE 'character_set_results';

7. 記憶口訣（文章收尾加分）

• utf8mb4 是唯一正確選擇
• utf8/utf8mb3 是歷史遺留
• MySQL 8 默認：utf8mb4_0900_ai_ci
• 要區(qū)分大小寫：用 utf8mb4_bin

最后一段總結（可直接當結尾）

跨環(huán)境最怕的不是“你寫錯”，而是“你沒寫”，讓默認值悄悄決定了線上行為。

所以：本地可以省略，項目/生產必須顯式指定。

只要把 utf8mb4 + 合理 collation 統(tǒng)一了，亂碼、emoji 報錯、比較排序異常、mix collations 等問題會少一大半。

到此這篇關于MySQL字符集與排序規(guī)則utf8mb4、utf8mb3、collation選型與避坑總結的文章就介紹到這了,更多相關MySQL utf8mb4、utf8mb3、collation內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論