MySQL utf8mb4_0900_ai_ci 怎样处理重音字符比较

在用户注册、搜索和排序场景里，e、é、É 看起来不同，但业务常常只关心“基础字母是不是同一个”。MySQL 的 utf8mb4_0900_ai_ci 正是为这种比较准备的：_ai 表示不区分重音，_ci 表示不区分大小写，0900 表示使用 UCA 9.0.0 的排序权重。

官方文档：https://dev.mysql.com/doc/refman/8.4/en/charset-unicode-sets.html

如果字段采用 utf8mb4_0900_ai_ci，重音和大小写通常不会参与普通字符串的相等、排序、分组与唯一性判断；需要保留重音差异时，应在查询或列定义上改用 accent-sensitive 排序规则，并用代表性数据回归。

为什么 é、É 与 e 可能被判定相等

一次故障通常表现为：插入带重音的用户名后，搜索能命中无重音写法，或者唯一索引拒绝了看似不同的值。根因不在 UTF-8 编码丢失字符，而在排序规则把字符映射到比较权重。MySQL 文档将 utf8mb4_0900_ai_ci 定义为基于 UCA 9.0.0、同时不区分重音和大小写的 Unicode 排序规则。

可以先用查询级规则复现边界。下面的字面量显式声明为 utf8mb4，避免连接字符集不同导致 COLLATE 不兼容：

-- 用三个字符验证重音层和大小写层是否被忽略
SELECT
  _utf8mb4'e' = _utf8mb4'é' COLLATE utf8mb4_0900_ai_ci AS accent_equal,
  _utf8mb4'e' = _utf8mb4'É' COLLATE utf8mb4_0900_ai_ci AS case_equal,
  COLLATION(_utf8mb4'é' COLLATE utf8mb4_0900_ai_ci) AS used_collation;
-- 预期：前两列为 1，最后一列明确显示 utf8mb4_0900_ai_ci

这里的“相等”只说明比较权重相同，并不表示 MySQL 把原始字符串改写成了 e，也不等于应用层做了 Unicode 规范化。读取原值时仍然可以得到原来的字符。

故障触发条件：查询规则和列规则不一致

如果列本身使用 utf8mb4_0900_ai_ci，普通的 =、LIKE、ORDER BY、GROUP BY 会沿用列或表达式的排序规则。临时业务需求可以在表达式上覆盖它，例如下面的查询只让本次比较区分重音：

-- 仅在本次查询保留重音差异，不改表结构
SELECT display_name
FROM account_name
WHERE display_name COLLATE utf8mb4_0900_as_ci = _utf8mb4'é' COLLATE utf8mb4_0900_as_ci;
-- _as 区分重音，_ci 仍然忽略大小写；结果取决于实际数据

utf8mb4_0900_as_ci 适合“é”和“e”要分开、但大小写仍不重要的场景；大小写和重音都必须区分时，选择 utf8mb4_0900_as_cs。显式 COLLATE 的好处是影响范围小，代价是同一业务规则容易散落在多条 SQL 中。

列、索引和唯一约束该怎么选

真正的修复要回到数据约束。若登录名的业务定义是“忽略大小写和重音仍视为同一名称”，列级使用 utf8mb4_0900_ai_ci 能让唯一索引与查询语义保持一致；若产品要求保留两个名字，则唯一索引也必须建立在 accent-sensitive 的列或表达式语义上，不能只改搜索 SQL。

-- 让列级语义与唯一约束保持一致；长度按业务字段调整
CREATE TABLE account_name (
  id BIGINT PRIMARY KEY,
  display_name VARCHAR(120)
    CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci NOT NULL,
  UNIQUE KEY uk_display_name (display_name)
);
-- 同一排序规则下，唯一性判断与普通等值查询不会互相打架

上线前至少用真实语言样本检查三组值：基础字母与重音字母、大小写变体、带组合字符的输入。还要查看表和列的实际定义，而不是只看服务器默认值：

-- 先确认真实列规则，再决定是否迁移
SHOW FULL COLUMNS FROM account_name;
SHOW CREATE TABLE account_name;
-- 迁移前对候选值做分组，提前发现唯一键冲突

不能把所有匹配都交给排序规则

MySQL 文档明确提醒，REGEXP 和 RLIKE 按字节工作，在多字节字符集上可能产生与普通排序规则不同的结果；重音字符是否相等不能从 LIKE 的表现推断到正则。需要正则搜索时，应针对目标版本、字符集和实际语料单独回归。

另一个边界是混合字符集或混合排序规则表达式。连接默认值、列定义、字符串字面量和显式 COLLATE 可能参与排序规则推导，遇到“Illegal mix of collations”时，先统一连接字符集和比较双方的排序规则，再判断业务是否真的需要覆盖列级定义。

修复后的复查清单

• 确认表、列、连接和字面量都使用兼容的 utf8mb4。
• 用 e/é/É 及目标语言样本分别验证等值、排序、分组和唯一插入。
• 把长期稳定的业务语义放到列定义，把一次性例外限制在查询级 COLLATE。
• 对 REGEXP、全文检索和跨库迁移单独做回归，不把它们当成普通字符串比较的别名。

相关问答

utf8mb4_0900_ai_ci 会删除重音吗？

不会。它改变的是比较和排序权重，原始字符串仍按输入保存；是否需要规范化或去重，要由应用和数据模型另行决定。

只在 SQL 中写 COLLATE 就够了吗？

临时查询通常够用，但如果唯一性、排序和所有搜索都应遵守同一规则，优先统一列级排序规则，并在迁移前处理已有重复数据。