字符集与排序规则：utf8mb4与乱码问题、排序规则影响查询结果——经验分享/踩坑向

字符集和排序规则这两件事，平时没人注意，一旦出问题就是“玄学”：明明存进去的中文，读出来变成问号；明明查的是 `ABC`，结果 `abc` 也匹配上了；更离谱的是，同一张表换个排序规则，唯一索引突然冲突。最近又踩了一轮，把经验整理一下，希望能帮你少加几个班。

从一次乱码排查说起

某次线上反馈：用户昵称里的 emoji 存不进去，接口直接报 `Incorrect string value: '\xF0\x9F...'`。第一反应是表字符集不对，一看建表语句：`CHARSET=utf8`。问题就出在这——MySQL 里的 `utf8` 并不是真正的 UTF-8，它最多只支持 3 字节，而 emoji、部分生僻字是 4 字节。`utf8mb4` 才是完整的 UTF-8 实现，所以现在新建库表，无脑选 `utf8mb4` 基本是标配。

但改成 `utf8mb4` 就万事大吉了吗？并没有。乱码问题往往是“链路”问题：客户端连接字符集、服务端默认字符集、表字符集、字段字符集，任何一环不一致都可能出幺蛾子。比如表已经是 `utf8mb4`，但连接串没加 `characterEncoding=utf8`，或者服务端 `character_set_client` 还是 `latin1`，写入时照样乱。排查时可以用 `SHOW VARIABLES LIKE 'character_set%';` 和 `SHOW VARIABLES LIKE 'collation%';` 看一眼，重点确认 `character_set_client`、`character_set_connection`、`character_set_results` 是不是 `utf8mb4`。连接层统一用 `SET NAMES utf8mb4;` 或 JDBC 的 `useUnicode=true&characterEncoding=utf8`，能省掉很多“为什么存进去是问号”的困惑。

排序规则不只是“大小写敏感”

字符集决定“能不能存”，排序规则决定“怎么比较”。很多人只记得 `_ci` 是大小写不敏感，`_bin` 是二进制比较，但实际影响面比想象中大。

常见排序规则：
- `utf8mb4_general_ci`：老默认，比较快，但 Unicode 排序规则不够严谨；
- `utf8mb4_unicode_ci`：基于 Unicode Collation Algorithm，相对更准确，MySQL 5.7 常用；
- `utf8mb4_0900_ai_ci`：MySQL 8.0 默认，`ai` 表示口音不敏感，`ci` 表示大小写不敏感；
- `utf8mb4_bin`：按二进制比较，大小写、重音都敏感。

这些规则直接影响 `WHERE`、`ORDER BY`、`GROUP BY`、`JOIN`，甚至唯一索引。踩过最狠的一次：某业务用邀请码做唯一索引，字段排序规则是 `utf8mb4_general_ci`，结果用户输入 `aBc` 和 `AbC` 被判定为重复，插入失败。业务上邀请码本该区分大小写，这就是排序规则选错导致的“查询结果不符合预期”。反过来，如果邮箱唯一索引用 `_bin`，`Test@xx.com` 和 `test@xx.com` 就能同时存在，但大多数业务又希望它们视为同一个邮箱。所以选 `ci` 还是 `bin`，不是技术偏好，而是业务语义。

排序规则不一致引发的隐式转换

更隐蔽的坑是 JOIN。两张表关联字段的排序规则不同，比如一张是 `utf8mb4_general_ci`，另一张是 `utf8mb4_unicode_ci`，执行 JOIN 时可能直接报：

`Illegal mix of collations (utf8mb4_general_ci,IMPLICIT) and (utf8mb4_unicode_ci,IMPLICIT) for operation '='`

即使不报错，也可能因为隐式转换导致索引失效，查询从毫秒变秒级。解决办法要么统一排序规则，要么在 SQL 里显式 `COLLATE`，但后者容易让索引失效，最好还是从建表规范上统一。

另外，`ORDER BY` 也受排序规则影响。中文按 `general_ci` 排出来的顺序，和按拼音排完全不是一回事。如果业务要求中文按拼音排序，MySQL 层面并不好直接满足，通常得靠应用层或额外排序字段。

一些实用的避坑建议

1. 新库新表统一 `utf8mb4`，MySQL 8.0 默认 `utf8mb4_0900_ai_ci`，5.7 建议 `utf8mb4_unicode_ci`。
2. 连接层显式设置字符集，别依赖服务端默认值。
3. 唯一索引、登录名、邀请码、订单号这类字段，先想清楚是否区分大小写，再决定用 `_ci`、`_cs` 还是 `_bin`。
4. JOIN 字段的字符集和排序规则保持一致。
5. 迁移时用 `ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;`，注意索引长度限制，必要时调整 `varchar` 长度或开启 `innodb_large_prefix`。

字符集和排序规则就像数据库里的“地基”，平时看不见，塌了才后悔。记住一句话：字符集管存储，排序规则管比较；统一 utf8mb4 是底线，按业务选 collation 才是进阶。下次再遇到乱码或者“查询结果不对”，先别怀疑人生，查查这两个参数，大概率能找到答案。