mysql字符集选型
1.mysql 字符集体
1.1 字符集 vs 排序规则
在 MySQL 里，“字符集（Character Set）”决定能存哪些字符、怎么编码；“排序规则（Collation）”决定怎么比较、排序、大小写是否敏感。
可以把字符集当成“字母表 + 编码方式”，排序规则当成“字典规则”。
show variables like ‘character_set%’;
1.2 MySQL 的层级模型
字符集可作用在 4 个层级：
- Server（全局默认）
- Database（库级）
- Table（表级）
- Column（字段级）
原则：越靠近数据，优先级越高。生产环境中，字段级通常是最终兜底。
2. MySQL 常见字符集分类
2.1 ASCII / latin1（历史遗留系）
2.1.1 ascii
- 仅支持 7-bit ASCII（0–127）
- 每字符 1 字节
应用场景：
- 协议字段、状态码、固定英文标识
- 对空间和性能极致敏感的元数据
评价：
现代业务几乎不再使用，更多是“技术化石”。
2.1.2 latin1
- 西欧字符集
- 单字节存储
- MySQL 早期默认字符集
应用场景：
- 不推荐
- 仅用于老系统兼容（尤其历史 MySQL 5.0/5.1）
风险：
中文写入会变成 ???，这是无数 DBA 的心理阴影。
2.2 Unicode 家族（主流与未来）
2.2.1 utf8（MySQL 特有的“半残版”）
- 最多 3 字节
- 不支持 4 字节字符（如 😀、🚀、部分 CJK 扩展）
应用场景：
- 旧系统
- 历史包袱迁移中
专家结论：
新系统不该再用 utf8，这是技术债的典型来源。
2.2.2 utf8mb4（事实标准）
- 真正的 UTF-8（1–4 字节）
- 支持 Emoji、全量 Unicode
应用场景：
- Web / App / IM / 国际化系统
- 含昵称、评论、搜索关键词的业务
- 微服务 + API 统一字符集
推荐排序规则：
utf8mb4_0900_ai_ci（MySQL 8.0+，基于 UCA 9.0）utf8mb4_general_ci（老版本，性能优先）utf8mb4_bin（精确比较，如 token、hash）
前瞻建议：
默认 utf8mb4 + 明确 collation，是当前和未来 10 年的安全解。
2.3 东亚字符集（区域特化）
2.3.1 gbk / gb2312
- 简体中文编码
- 双字节为主
应用场景：
- 老国标系统
- 与特定中间件 / 国密系统对接
问题：
- 不支持繁体、日韩
- 国际化能力差
2.3.2 big5
- 繁体中文（台湾、港澳）
应用场景：
- 特定地区老系统
评价：
逐步被 utf8mb4 取代，属于“保守孤岛”。
2.3.3 ujis / euckr / sjis
- 日文、韩文相关编码
应用场景：
- 极老的本地化系统
- 几乎只剩兼容价值
2.4 二进制字符集
2.4.1 binary
- 不做字符解析
- 按字节比较
应用场景：
- 哈希值（MD5 / SHA）
- 加密数据
- Token / 签名
思维误区：
binary 不是“更快的 utf8”，它是完全不同的语义层级。
3. 排序规则（Collation）选型策略
3.1 常见对比维度
_ci：不区分大小写_cs：区分大小写_ai：忽略重音_bin：字节级精确比较
3.2 典型组合建议
- 用户名 / 昵称：
utf8mb4_0900_ai_ci - 登录账号：
utf8mb4_bin - 搜索字段：
utf8mb4_0900_ai_ci - 业务编码 / 枚举值：
ascii + bin
- 架构级最佳实践
4.1 全链路统一模型
- MySQL：utf8mb4
- 连接层：
SET NAMES utf8mb4 - ORM / Driver：明确 charset
- API：UTF-8 JSON
字符集不统一，本质是数据腐蚀。
4.2 新系统默认模板
1 | CREATE DATABASE app_db |
5. 一句话总结
- latin1 / utf8：历史包袱
- gbk / big5：区域遗产
- utf8mb4：现在与未来
- binary：非文本，不要混用