mysql 8.0升级后唯一索引冲突主因是utf8mb4_0900_ai_ci将罗马数字Ⅰ与字母i等归一化为相同值，属排序规则语义变更；需通过select 'Ⅰ'='i'验证、show full columns查字段collation，并按业务语义选择alter table modify改用_as_cs或_unicode_ci等策略修复。
MySQL 8.0 升级后唯一索引冲突，大概率不是数据错了，而是 utf8mb4_0900_ai_ci 把原本区分的字符（比如罗马数字 Ⅰ 和字母 I）当成相同值处理了——这属于排序规则语义变更，不是 bug，但必须主动应对。
查清哪些字段触发了唯一索引“误判”
先确认冲突是否真由 collation 引起：执行 SELECT 'Ⅰ' = 'I', 'Ⅱ' = 'II';，如果返回 1，说明当前会话或字段用了 utf8mb4_0900_ai_ci；再查出问题表字段的真实 collation：
-
SHOW FULL COLUMNS FROM your_table LIKE 'col_name';—— 看字段级 collation -
SELECT @@collation_connection, @@collation_database;—— 看连接和库默认值 - 若涉及 JOIN 或子查询，两边字段 collation 都得查，不一致就会放大误判范围
修复唯一索引冲突的三种实操路径
不能一刀切改全局配置，得按字段语义选策略：
- 对「必须严格区分」的字段（如 token、订单号、密码哈希），用
ALTER TABLE t MODIFY col VARCHAR(32) COLLATE utf8mb4_0900_as_cs;——_as_cs区分大小写+重音，彻底避免归一化 - 对「业务上允许模糊匹配」的字段（如用户名搜索），保留
_ai_ci，但在应用层加LOWER()或建函数索引：CREATE INDEX idx_uname_lower ON users ((LOWER(username))); - 历史老表不想动结构？在 INSERT/UPDATE 时显式指定 collation：
INSERT INTO t (id, code) VALUES (1, 'testⅠ' COLLATE utf8mb4_unicode_ci);
ALTER TABLE 改 collation 容易踩的坑
直接用 CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci 是高危操作：
- 它会重写整张表，锁表时间长，线上慎用
- 若字段原来定义了
COLLATE utf8mb4_general_ci，CONVERT TO可能覆盖成_0900_ai_ci，反而加剧与其它表的 JOIN 冲突 - 安全做法是用
MODIFY或CHANGE显式重申字段定义，例如：ALTER TABLE t CHANGE col col VARCHAR(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; - 改完立刻验证：
SHOW CREATE TABLE t;确认字段 collation 已更新，再跑冲突 SQL 测试
最常被忽略的是连接层 collation —— 表和字段改得再准，如果 @@collation_connection 还是 utf8mb4_0900_ai_ci，而应用传入的字面量没显式指定 collation，比较时仍会走归一化逻辑。所以 JDBC 要加 collationConnection=utf8mb4_unicode_ci，PHP 要在连接后执行 SET NAMES utf8mb4 COLLATE utf8mb4_unicode_ci。
