utf8mb4 排序规则怎么选：大小写、重音与唯一键影响

utf8mb4 排序规则要按“这个字段应该把哪些值视为相同”来选，而不是看到默认值就整库照搬。面向用户的名称搜索，通常希望忽略大小写，是否忽略重音要看业务；账号名、外部编码、幂等键则往往需要更严格的区分。这个判断还会直接进入 UNIQUE 索引：排序规则认为相等的两个字符串，不能同时成为唯一值。

官方资料：https://dev.mysql.com/doc/refman/8.4/en/

先把排序规则拆成可判断的三个维度

MySQL 的 collation 是比较和排序的一组规则。名称后缀可以先给出一个可操作的判断：ci 是 case-insensitive，cs 是 case-sensitive；ai 是 accent-insensitive，as 是 accent-sensitive；bin 按二进制权重比较。比如 utf8mb4_0900_ai_ci 同时忽略大小写和重音，utf8mb4_0900_as_cs 两者都区分。

字段的使用方式比“中文还是英文”更重要。昵称、商品名、城市名通常先考虑搜索体验；登录名、租户编码、外部系统主键则要先问清楚大小写是不是有意义。重音敏感也不能凭感觉决定，国际化名称可能需要区分 cafe 与 café。

用 SHOW COLLATION 先确认候选规则

不要只凭记忆拼排序规则名称。服务器、数据库、表、列和字符串字面量都可能提供默认字符集或排序规则，列级配置最接近字段本身的约束。先列出当前实例可用的 utf8mb4 规则，再看默认项和尾随空格属性：

-- 先确认实例实际提供哪些 utf8mb4 排序规则和尾随空格策略
SHOW COLLATION WHERE Charset = 'utf8mb4';

-- 只查看 0900 系列，重点比较 Default 与 Pad_attribute
SELECT COLLATION_NAME, IS_DEFAULT, PAD_ATTRIBUTE
FROM INFORMATION_SCHEMA.COLLATIONS
WHERE CHARACTER_SET_NAME = 'utf8mb4'
  AND COLLATION_NAME LIKE 'utf8mb4\\_0900%'
ORDER BY COLLATION_NAME;

-- 让字段级语义显式化，避免依赖表或服务器默认值
CREATE TABLE customer_alias (
  id BIGINT PRIMARY KEY,
  display_name VARCHAR(120)
    CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci,
  external_code VARCHAR(80)
    CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_as_cs,
  UNIQUE KEY uk_external_code (external_code)
);

MySQL 8.4 的 utf8mb4 默认排序规则是 utf8mb4_0900_ai_ci，但迁移脚本不应把“当前默认”当成永久契约。旧环境可能使用 utf8mb4_general_ci 或 utf8mb4_unicode_ci，应在目标实例上重新检查名称、可用性和比较结果。

唯一键会把“比较相等”变成数据冲突

排序规则不仅影响 ORDER BY。当字符列有唯一索引时，MySQL 会按该列的比较规则判断是否重复。于是 utf8mb4_0900_ai_ci 下，大小写不同的账号名可能被判为同一个值；在重音不敏感规则下，带重音和不带重音的拉丁字母也可能发生冲突。

尾随空格还要看 PAD_ATTRIBUTE：PAD SPACE 比较时忽略字符串末尾空格，NO PAD 则把它作为有意义的字符。下面的检查把“业务样本”和“索引约束”放在一起，适合迁移前先跑在临时表上：

-- 用显式 COLLATE 对照同一批样本，避免只观察自然语言排序
SELECT
  'Cafe' = 'cafe' COLLATE utf8mb4_0900_ai_ci AS ci_equal,
  'cafe' = 'café' COLLATE utf8mb4_0900_ai_ci AS ai_equal,
  'Cafe' = 'cafe' COLLATE utf8mb4_0900_as_cs AS cs_equal;

-- 唯一键测试要覆盖大小写、重音和尾随空格三类边界
CREATE TABLE collation_probe (
  value_text VARCHAR(40)
    CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_as_cs,
  UNIQUE KEY uk_value (value_text)
);

-- 这些值是否能同时插入，取决于列的排序规则；错误应被记录而非忽略
INSERT INTO collation_probe(value_text)
VALUES ('Cafe'), ('cafe'), ('café'), ('cafe ');

选择与迁移时保留一张小清单

可以按下面的顺序落地：先写出“哪些值应该相等”，再选排序规则；随后对候选规则执行 SHOW COLLATION 和样本比较；接着扫描现有数据中可能合并的值，最后才修改列和唯一键。生产迁移还要确认应用连接字符集、索引长度、回滚方式和主从版本是否一致。

真正需要避免的是“全库统一一个排序规则”。排序规则属于字段语义：用户搜索和机器标识可以在同一张表里使用不同配置。把选择写入建表迁移文件，并在测试数据中固定 Cafe、café、cafe 这类边界样本，后续升级 MySQL 或重建索引时才不容易出现隐性重复。

常见问题

utf8mb4_0900_ai_ci 能不能用于所有唯一键？

不建议。它适合“用户输入的不同写法应归并”的搜索字段，但账号名、外部编码等字段往往需要区分大小写或重音，应依据业务契约选择更严格的规则。

排序规则只影响 ORDER BY 吗？

不是。等值比较、LIKE、部分全文搜索和唯一索引判重都会受到比较规则影响，不能只看列表排序是否符合预期。

修改 collation 前最该检查什么？

先检查现有数据在新规则下是否会出现等值合并，再检查唯一索引、应用连接字符集和回滚脚本。若结果不清晰，先复制到临时表做插入试验。