MySQL utf8mb4 排序规则变化会影响唯一索引吗

会，而且影响的不只是排序显示。MySQL 的排序规则决定字符串怎样比较；唯一索引依赖的正是这种“是否相等”的判断。把列从 utf8mb4_bin 改成大小写不敏感的 utf8mb4_0900_ai_ci，可能让原来可同时存在的两行变成冲突；从 PAD SPACE 改成 NO PAD，又可能改变尾随空格的边界。

官方文档：https://dev.mysql.com/doc/refman/8.4/en/

先分清 utf8mb4、排序规则和唯一索引

utf8mb4 是字符集，负责可表示的字符与编码；utf8mb4_0900_ai_ci、utf8mb4_bin 等才是比较和排序规则。列可以显式指定自己的 COLLATE，没有显式指定时才会沿用表级默认值，因此只改数据库默认排序规则，不会自动改完已有列。

唯一索引要求索引键值彼此不同。对 VARCHAR 列来说，MySQL 会按该列的排序规则判断是否相等，所以 Account 与 account 是否冲突，取决于规则的大小写敏感性；尾随空格是否参与比较，则取决于 PAD_ATTRIBUTE。

-- 中文注释：把列级规则、索引角色和排序规则属性放在一起查看
SELECT c.TABLE_SCHEMA, c.TABLE_NAME, c.COLUMN_NAME,
       c.COLUMN_TYPE, c.COLLATION_NAME, c.COLUMN_KEY,
       co.PAD_ATTRIBUTE
FROM INFORMATION_SCHEMA.COLUMNS AS c
LEFT JOIN INFORMATION_SCHEMA.COLLATIONS AS co
  ON co.COLLATION_NAME = c.COLLATION_NAME
WHERE c.TABLE_SCHEMA = 'app'
  AND c.TABLE_NAME = 'user_account'
  AND c.COLUMN_NAME = 'login_name';

-- 中文注释：确认唯一键到底由哪些列按什么顺序组成
SHOW CREATE TABLE app.user_account;

排序规则变化具体会改变哪些相等关系

不要只凭名称猜结果。官方资料明确区分 PAD SPACE 和 NO PAD：前者在非二进制字符串比较中忽略末尾空格，后者把末尾空格视为普通字符。以 utf8mb4 为例，utf8mb4_bin 是 PAD SPACE，而 utf8mb4_0900_bin 是 NO PAD。这意味着排序规则变化可能让插入、等值查询、DISTINCT 和唯一约束同时改变。

-- 中文注释：用代表性样本比较大小写与尾随空格，结果只用于迁移前判断
SELECT
  'Account' = 'account' COLLATE utf8mb4_bin AS bin_case_equal,
  'Account' = 'account' COLLATE utf8mb4_0900_ai_ci AS ai_case_equal,
  'a' = 'a ' COLLATE utf8mb4_bin AS bin_pad_equal,
  'a' = 'a ' COLLATE utf8mb4_0900_bin AS bin0900_pad_equal;

-- 中文注释：列出目标实例实际支持的规则和尾随空格属性
SELECT COLLATION_NAME, PAD_ATTRIBUTE
FROM INFORMATION_SCHEMA.COLLATIONS
WHERE COLLATION_NAME IN ('utf8mb4_bin', 'utf8mb4_0900_bin', 'utf8mb4_0900_ai_ci');

这里的查询结果不是“新规则一定更严格”这么简单：某些不区分大小写或重音的规则会合并更多值，NO PAD 又会把尾随空格区分开。真正要迁移的是业务标识，就应拿业务中的真实边界样本比较，而不是只测一个英文单词。

迁移前先按目标规则找唯一索引冲突

最危险的信号是：当前数据在旧规则下不重复，但按目标规则分组后出现多行。先记录主键、原始值和冲突组，交给业务决定保留、合并还是改写；不要在正式变更时才让 ALTER TABLE 替你做决策。

-- 中文注释：显式使用目标规则，提前找出会合并的登录名
SELECT login_name COLLATE utf8mb4_0900_ai_ci AS normalized_name,
       COUNT(*) AS row_count,
       GROUP_CONCAT(id ORDER BY id) AS row_ids
FROM app.user_account
WHERE login_name IS NOT NULL
GROUP BY login_name COLLATE utf8mb4_0900_ai_ci
HAVING COUNT(*) > 1;

-- 中文注释：单独找尾随空格样本，避免清洗时误伤有意义的值
SELECT id, login_name, CHAR_LENGTH(login_name) AS char_len,
       LENGTH(login_name) AS byte_len
FROM app.user_account
WHERE login_name  RTRIM(login_name);

MySQL 官方也提示，修改字符集或排序规则时出现 duplicate-key，通常意味着新列规则把两个键映射成了同一个值。这个错误是有价值的迁移证据：保留冲突清单，处理数据后再重试，不要关闭唯一检查或改成宽松索引。

执行变更时把规则写死并留好回退点

确认冲突已经处理后，再在低峰期或维护窗口执行明确的列定义变更。这里的 NOT NULL、长度和默认值要以现有表结构为准，示例只演示把规则写在列上：

-- 中文注释：示例把列固定为目标字符集和排序规则，生产前先核对原列属性
ALTER TABLE app.user_account
  MODIFY login_name VARCHAR(128)
  CHARACTER SET utf8mb4
  COLLATE utf8mb4_0900_ai_ci
  NOT NULL;

-- 中文注释：变更后复查列级规则与唯一索引，确认没有只改到表默认值
SELECT COLUMN_NAME, COLUMN_TYPE, COLLATION_NAME, COLUMN_KEY
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_SCHEMA = 'app'
  AND TABLE_NAME = 'user_account'
  AND COLUMN_NAME = 'login_name';
SHOW CREATE TABLE app.user_account;

回退不是简单地把数据库默认值改回去，而是把同一列恢复到原来的完整定义，并重新评估已经清洗过的数据。应用连接也要统一字符集与连接排序规则，避免读写端用不同规则解释同一个标识。

常见问题

只修改表的 DEFAULT COLLATE，会重建已有唯一索引吗？

不会替代列级定义。已有列若有自己的 COLLATE，仍以列级规则为准；应通过 SHOW CREATE TABLE 和 INFORMATION_SCHEMA.COLUMNS 确认。

唯一索引冲突只会在 INSERT 时出现吗？

不一定。改变排序规则的重建过程也可能因新规则合并现有键而失败，等值查询、分组和去重结果也可能随之变化。

把字段改成二进制排序规则就一定安全吗？

不一定。二进制规则会改变大小写、重音与排序语义，业务登录名、邮箱或自然语言字段要先确认是否需要语言规则；标识字段还要单独处理规范化策略。