MySQL 字符集与排序规则总结

一、DEFAULT CHARACTER SET 是否必须写

一句话结论

如果你的 MySQL 8.x 已经是 utf8mb4，DEFAULT CHARACTER SET utf8mb4 可以不写。

为什么 DataGrip 默认不写？

DataGrip 的逻辑：

不写 = 用服务器当前默认配置
在 MySQL 8.x 中，默认就是：
- character_set_server = utf8mb4
- collation_server = utf8mb4_0900_ai_ci

所以它省略了。

不写时，实际等价于什么？

下面两句效果完全一样：

sql 复制代码

-- 不写（DataGrip 默认）
CREATE DATABASE app_db;

-- 显式写（等价）
CREATE DATABASE app_db
  DEFAULT CHARACTER SET utf8mb4
  COLLATE utf8mb4_0900_ai_ci;

前提： 你没改过 MySQL 的全局配置。

什么时候「一定要写」？

✅ 情况 1：不确定环境

别人的服务器
老 MySQL 5.7
线上环境

👉 强烈建议写，防止踩坑

✅ 情况 2：项目有严格规范（团队协作）

为了：

所有人环境一致
不被服务器配置"偷偷影响"

👉 写出来更安全

✅ 情况 3：要兼容中文 / emoji

sql 复制代码

DEFAULT CHARACTER SET utf8mb4

写了就 100% 没问题。

什么时候「可以放心不写」？

✅ 你现在这个场景：

MySQL 8.x
本地开发
DataGrip
新建数据库

👉 可以不写，完全 OK

怎么确认你现在的默认值？

sql 复制代码

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

只要看到：

utf8mb4
utf8mb4_0900_ai_ci

就放心。

开发习惯建议

场景	建议
本地学习 / 临时库	不写
正式项目 / 提交 SQL	写
生产环境	必须写

总结

DataGrip 不写不是少了，而是"默认已经是 utf8mb4"
写不写都对，区别在于：你要不要把环境固定死

二、utf8mb3 vs utf8mb4

一句话总览

永远优先用 utf8mb4
utf8mb3 = 老的、不完整的 UTF-8（已废弃）
utf8mb4 = 真正的 UTF-8（支持 emoji）

核心区别对比

特性	utf8mb3（旧）	utf8mb4（推荐）
最大字节	3 字节	4 字节
支持 emoji	❌ 不支持	✅ 支持
支持所有 Unicode	❌ 不完整	✅ 完整
MySQL 8 状态	已废弃（Deprecated）	✅ 默认
推荐程度	❌ 永远不要用	⭐⭐⭐⭐⭐

utf8mb3 的问题

📌 举例（会直接报错）：

sql 复制代码

-- utf8mb3 下插入 emoji 会失败
INSERT INTO user(username) VALUES ('张三😊'); -- ❌ 报错

为什么会被废弃？

只支持 3 字节 UTF-8，无法表示完整的 Unicode
不支持 emoji、特殊符号等 4 字节字符
MySQL 8.0 开始标记为废弃

utf8mb4 的优势

✅ 支持所有 Unicode 字符

中文、日文、韩文
Emoji（😊 😂 👍）
特殊符号

✅ MySQL 8.x 默认字符集

✅ 未来标准

为什么你还会看到 utf8mb3？

原因：

老项目（MySQL 5.x）
很久以前建的库 / 表
旧教程 / 旧博客
历史兼容

⚠️ 新项目再用 utf8mb3 = 技术债

三、排序规则对比

常见排序规则

1. utf8mb4_unicode_ci（旧版）

组成：

utf8mb4 → 字符集
unicode → Unicode 排序算法（老版）
ci → case-insensitive（不区分大小写）

特点：

比 general_ci 排序更准确
比 0900_ai_ci 旧
速度略慢
MySQL 5.7 常用

2. utf8mb4_0900_ai_ci（推荐）

组成：

utf8mb4 → 字符集
0900 → Unicode 9.0 版本（新版）
ai → accent-insensitive（不区分重音）
ci → case-insensitive（不区分大小写）

特点：

✅ MySQL 8.x 默认
✅ 排序更准确
✅ 性能更好
✅ 中文排序更准确

排序规则对比表

对比项	unicode_ci	0900_ai_ci
Unicode 版本	旧（< 9.0）	9.0（新）
中文排序	正确	更准确
拼音 / 重音	一般	更好
MySQL 8 默认	❌	✅
性能	略慢	更快

大小写区分说明

后缀	含义	示例
`_ci`	case-insensitive（不区分大小写）	'A' = 'a'
`_bin`	binary（区分大小写）	'A' ≠ 'a'

示例：

sql 复制代码

-- 不区分大小写（默认）
username VARCHAR(50) COLLATE utf8mb4_0900_ai_ci
-- 'Tom' = 'tom' = 'TOM'

-- 区分大小写
username VARCHAR(50) COLLATE utf8mb4_bin
-- 'Tom' ≠ 'tom'

四、实际应用建议

新项目选择（推荐）

sql 复制代码

CREATE DATABASE app_db
  DEFAULT CHARACTER SET utf8mb4
  COLLATE utf8mb4_0900_ai_ci;

选择理由：

✅ utf8mb4：支持所有字符（含 emoji）
✅ utf8mb4_0900_ai_ci：MySQL 8 默认，性能好，排序准确

老项目兼容（必须）

sql 复制代码

CREATE DATABASE app_db
  DEFAULT CHARACTER SET utf8mb4
  COLLATE utf8mb4_unicode_ci;

使用场景：

需要兼容 MySQL 5.7
已有表使用 unicode_ci

永远不要再用

❌ utf8（实际是 utf8mb3 的别名） ❌ utf8mb3（已废弃）

常见"坑位"提醒

1. 唯一索引长度问题（老版本）

问题：

utf8mb4 下：VARCHAR(255) = 255 × 4 = 1020 bytes
老 MySQL 可能索引失败（索引最大 767 bytes）

解决：

✅ MySQL 8 已解决，不用担心
MySQL 5.7 需要调整：VARCHAR(191) 或使用前缀索引

2. 字段级字符集设置

sql 复制代码

-- 表级设置
CREATE TABLE user (
  username VARCHAR(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci
);

注意： 通常不需要字段级设置，继承表/库的默认值即可。

五、快速参考

标准建库模板

MySQL 8.x（推荐）

sql 复制代码

CREATE DATABASE app_db
  DEFAULT CHARACTER SET utf8mb4
  COLLATE utf8mb4_0900_ai_ci;

MySQL 5.7 兼容

sql 复制代码

CREATE DATABASE app_db
  DEFAULT CHARACTER SET utf8mb4
  COLLATE utf8mb4_unicode_ci;

字符集选择速查表

场景	字符集	排序规则	说明
新项目（MySQL 8）	utf8mb4	utf8mb4_0900_ai_ci	⭐ 推荐
老项目兼容	utf8mb4	utf8mb4_unicode_ci	兼容 MySQL 5.7
需要区分大小写	utf8mb4	utf8mb4_bin	特殊场景
❌ 不要用	utf8mb3	-	已废弃

验证当前配置

sql 复制代码

-- 查看服务器默认字符集
SHOW VARIABLES LIKE 'character_set_server';
SHOW VARIABLES LIKE 'collation_server';

-- 查看数据库字符集
SHOW CREATE DATABASE app_db;

-- 查看表字符集
SHOW CREATE TABLE user;

记忆口诀

ini 复制代码

utf8mb4 是唯一正确选择
utf8mb3 是历史遗留
unicode_ci 能用但已不是最优
MySQL 8 = utf8mb4_0900_ai_ci

总结

核心要点

字符集选择
- ✅ 永远用 utf8mb4
- ❌ 永远不用 utf8mb3
排序规则选择
- MySQL 8.x：utf8mb4_0900_ai_ci（推荐）
- MySQL 5.7：utf8mb4_unicode_ci（兼容）
DEFAULT CHARACTER SET
- MySQL 8.x 本地开发：可以不写
- 正式项目 / 生产环境：必须写
开发习惯
- 本地学习：不写（用默认）
- 正式项目：写（固定环境）
- 生产环境：必须写

一句话总结

utf8mb4 是唯一正确选择
utf8mb3 是历史遗留
unicode_ci 能用但已不是最优
MySQL 8 = utf8mb4_0900_ai_ci

MySQL 字符集与排序规则总结

目录

一、DEFAULT CHARACTER SET 是否必须写

一句话结论

为什么 DataGrip 默认不写？

不写时，实际等价于什么？

什么时候「一定要写」？

✅ 情况 1：不确定环境

✅ 情况 2：项目有严格规范（团队协作）

✅ 情况 3：要兼容中文 / emoji

什么时候「可以放心不写」？

怎么确认你现在的默认值？

开发习惯建议

总结

二、utf8mb3 vs utf8mb4

一句话总览

核心区别对比

utf8mb3 的问题

utf8mb4 的优势

为什么你还会看到 utf8mb3？

三、排序规则对比

常见排序规则

1. utf8mb4_unicode_ci（旧版）

2. utf8mb4_0900_ai_ci（推荐）

排序规则对比表

大小写区分说明

四、实际应用建议

新项目选择（推荐）

老项目兼容（必须）

永远不要再用

常见"坑位"提醒

1. 唯一索引长度问题（老版本）

2. 字段级字符集设置

五、快速参考

标准建库模板

MySQL 8.x（推荐）

MySQL 5.7 兼容

字符集选择速查表

验证当前配置

记忆口诀

总结

核心要点

一句话总结