MySQL utf8mb4 排序规则变化后为什么结果顺序不同

utf8mb4 决定字符如何编码，排序规则 collation 决定字符串如何比较。即使字节内容与字符集完全没变，更换 collation 也可能改变字符权重、大小写和重音的相等判断，以及尾部空格的处理，因此 ORDER BY、分组去重和唯一索引的行为都可能变化。

遇到“迁移后名单顺序不一样”，我会先区分比较规则变了，还是相同排序值之间本就没有指定先后。这是排查顺序的建议，不是对某次实际迁移的运行记录。下面按 MySQL 8.4 手册准备一个独立小实验。官方入口：https://dev.mysql.com/doc/refman/8.4/en/charset-collation-names.html。

前置条件：查列定义，不只看服务器默认值

排序规则可以来自列定义，也可以由表达式中的 COLLATE 明确指定。仅发现服务器默认规则发生变化，并不能证明已有列也被修改。先看实际列及查询文本，再讨论迁移原因。

-- 用真实业务表替换 catalog_items；只读取结构，不修改原表。
SHOW FULL COLUMNS FROM catalog_items;
SHOW CREATE TABLE catalog_items;

-- 规则属性从服务器支持列表中读取，确认目标规则确实可用。
SELECT COLLATION_NAME, CHARACTER_SET_NAME, PAD_ATTRIBUTE
FROM information_schema.COLLATIONS
WHERE COLLATION_NAME IN (
    'utf8mb4_unicode_ci', 'utf8mb4_0900_ai_ci',
    'utf8mb4_0900_as_cs'
);

名称中的 ai 表示不区分重音，as 表示区分重音，ci 表示不区分大小写，cs 表示区分大小写。0900 指所依据的 Unicode 排序算法版本，不是字符编码位数。不同语言定制规则也可能影响相对次序，不能只看后缀是否都是 ci。

初始化：在同一连接准备样本

实验使用临时表，样本是虚构标签，包含大写、小写、重音字母和尾部空格。所有语句应在同一连接执行，因为临时表属于该会话。插入值使用十六进制 UTF-8 字面量，避免复制时丢掉尾部空格。

-- 新建演示临时表，不占用业务表；重复实验前先清理本会话旧表。
DROP TEMPORARY TABLE IF EXISTS demo_collation_labels;
CREATE TEMPORARY TABLE demo_collation_labels (
    id INT PRIMARY KEY,
    label VARCHAR(30) CHARACTER SET utf8mb4
        COLLATE utf8mb4_0900_as_cs NOT NULL
);

-- 内容依次为 A、a、带重音的 á、a 后带一个空格、b。
INSERT INTO demo_collation_labels (id, label) VALUES
    (1, _utf8mb4 0x41),
    (2, _utf8mb4 0x61),
    (3, _utf8mb4 0xC3A1),
    (4, _utf8mb4 0x6120),
    (5, _utf8mb4 0x62);

编写比较查询：先看相等，再看排序

如果两条字符串在规则下被认为相等，它们单靠这一列就没有唯一先后。下面先比较 A 与 a，再对同一批数据显式指定两种规则。SQL 和结果解释是按官方语义推导的示例，未展示现场运行数据。

-- 同一组 UTF-8 字符只更换比较规则：预期分别为 1 与 0。
SELECT
    (_utf8mb4 0x41 COLLATE utf8mb4_0900_ai_ci =
     _utf8mb4 0x61 COLLATE utf8mb4_0900_ai_ci) AS eq_ai_ci,
    (_utf8mb4 0x41 COLLATE utf8mb4_0900_as_cs =
     _utf8mb4 0x61 COLLATE utf8mb4_0900_as_cs) AS eq_as_cs;

-- id 给规则认为相等的标签提供唯一先后；HEX 显示尾部空格。
SELECT id, label, HEX(label) AS utf8_bytes
FROM demo_collation_labels
ORDER BY label COLLATE utf8mb4_0900_ai_ci, id;

-- 这里只更换规则，样本与字节不变。
SELECT id, label, HEX(label) AS utf8_bytes
FROM demo_collation_labels
ORDER BY label COLLATE utf8mb4_0900_as_cs, id;

ai_ci 下 A、a 与 á 属于相同的比较权重，id 用来裁决它们的展示次序；as_cs 则区分大小写和重音。不要把某个样本的排序顺序推广成所有语言的字典顺序，也不要假设换规则后每一对字符串的位置都会改变。

例如 utf8mb4_unicode_ci 的 PAD_ATTRIBUTE 为 PAD SPACE，而 utf8mb4_0900_ai_ci 为 NO PAD。对非二进制字符串比较，后者把尾空格当作普通字符。不要用“都是 utf8mb4”判断它们的比较结果相同。

迁移影响：索引与分页也要采用相同口径

唯一索引依赖列的比较语义。如果原来能区分的值在新规则下相等，变更或重建唯一索引就可能遇到重复值冲突。反过来，新规则区分更多值也意味着后续写入可能接受旧规则认为重复的名称。应先明确同名定义，再决定如何处理冲突，而不是临时删掉唯一约束。

普通字符索引也按照列的规则组织比较。查询临时加另一个 COLLATE 不会把原索引自动变成目标规则的排序索引，不能承诺原来的索引排序路径仍然适用。生产列变更的重建成本和锁行为需要结合具体表结构与 DDL 方式另行评估，本文不提供直接修改业务表的通用命令。

列表应写成明确的 ORDER BY label COLLATE 目标规则, id。但唯一 id 只能稳定目标规则中的同权重记录，不能恢复旧规则的整个排序。游标分页若用 label 与 id 作为续查条件，比较条件也必须与排序口径一致；迁移前生成的游标不应直接假定仍代表同一个位置。

清理实验与实际取舍

-- 只删除本会话的演示临时表，业务表保持原状。
DROP TEMPORARY TABLE IF EXISTS demo_collation_labels;

我的取舍是先定义名称相等和展示次序，再选规则。大小写敏感的标识符与面向用户的姓名列表未必适合同一套规则；不能仅凭名称更新就把所有列统一替换。

改了数据库默认规则，旧列会自动跟着变化吗？

不能这样推断。默认值与实际列定义是不同层级，应以列定义和查询表达式为准。

加 id 排序能解决所有变化吗？

只能解决相同比较权重之间的确定先后，无法抵消规则本身对字符顺序与相等关系的调整。

换成二进制排序就一定符合业务吗？

不一定。按字符代码值或字节进行比较与自然语言排序并不相同；即使是不同的 _bin 规则，尾空格属性也可能不同。

参考：排序规则命名；Unicode 规则及空格属性；列级字符集与排序规则。