解读

面试官抛出该问题，核心想考察两点：

1. 你是否真的踩过国内 MySQL 8.0 上云的坑，尤其是utf8mb4_0900_ai_ci这把“双刃剑”；
2. 面对 Google Cloud SQL for MySQL（目前主流版本 8.0）时，能否提前识别排序规则冲突并给出可落地的规避方案。
   在国内场景下，源库往往是阿里云 RDS 5.7、腾讯云 MySQL 5.6或自建 5.7，默认排序规则还是utf8mb4_general_ci或utf8mb4_unicode_ci；一旦直接导入到 Cloud SQL 8.0 并沿用utf8mb4_0900_ai_ci，就会出现索引失效、主键冲突、JOIN 结果异常、业务 SQL 排序错乱等“幽灵问题”。回答时必须把风险根因、触发条件、故障现象、检测手段、修复路径一次性讲清，才能体现“资深 DBA”段位。

知识点

1. 排序规则（Collation）优先级：MySQL 8.0 将utf8mb4_0900_ai_ci设为utf8mb4 默认，而 5.7 默认是utf8mb4_general_ci；两者不区分大小写但排序权重表完全不同。
2. 索引前缀长度限制：0900 规则使用NO PAD语义，导致CHAR/VARCHAR 键值在 5.7 里能建 767 字节索引，到 8.0 却可能超长 3072 字节报错。
3. JOIN 隐式转换：当左表字段是utf8mb4_general_ci、右表字段是utf8mb4_0900_ai_ci时，MySQL 会隐式转换字符集，造成索引失效并退化为全表扫描+filesort，QPS 直接掉 90%。
4. 主从复制风险：若源库 5.7 使用utf8mb4_unicode_ci、Cloud SQL 8.0 使用utf8mb4_0900_ai_ci，同值不同权重会导致唯一键冲突，row 格式复制直接中断，报错1062 Duplicate entry。
5. 国内合规要求：等保 2.0 要求数据完整性可追溯，若因排序规则差异导致业务逻辑结果不一致，会被审计判定为数据篡改风险。

答案

迁移到 Google Cloud SQL for MySQL 8.0 后，若目标库默认采用utf8mb4_0900_ai_ci，而源库是5.7 的 utf8mb4_general_ci/utf8mb4_unicode_ci，会引入三类显性兼容性风险：

1. 排序结果漂移：同样 SELECT … ORDER BY name，在 5.7 里“啊”排在“阿”前，在 8.0 里顺序相反，导致分页错乱；国内电商大促期间曾出现订单列表跳号，用户投诉“刷单”。
2. 唯一键冲突：字符串“ß”在utf8mb4_general_ci里等于“ss”，在utf8mb4_0900_ai_ci里却不等；结果批量导入时ß与ss被当作两值，唯一索引不冲突，但业务主键重复，财务对账出现一分钱差额。
3. 索引不可用：JOIN 条件里t1.col general_ci = t2.col 0900_ai_ci会触发隐式转换，执行计划Extra出现Using where; Using filesort，慢查询从 50 ms 涨到 8 s，P99 latency 直接击穿国内 SLA 300 ms红线。

检测手段：

• 在 Cloud SQL 侧执行

  SELECT TABLE_NAME,COLUMN_NAME,CHARACTER_SET_NAME,COLLATION_NAME
  FROM information_schema.COLUMNS
  WHERE COLLATION_NAME RLIKE '0900';
  

  若结果集非空，说明已存在0900 规则字段。
• 用pt-table-checksum对比源库与 Cloud SQL 的CRC，若** diffs > 0** 即可确认数据逻辑不一致。

修复路径：

1. 迁移前统一降级：在 Cloud SQL 参数组里把collation_server、collation_connection显式设为utf8mb4_general_ci，并重启实例；随后mysqldump加**–default-character-set=utf8mb4 –set-charset保证DDL 里 COLLATE 原样保留**。
2. 迁移后原地修改：对已有 0900 字段执行

ALTER TABLE tbl CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

注意ALGORITHM=INPLACE在国内 100 G 大表场景可能耗时 30 min，需低峰期+Binlog 限速。
3. 连接层兜底：在Spring Boot 2.7的jdbc url后追加**&connectionCollation=utf8mb4_general_ci**，防止新写入再次使用 0900 规则。

一句话总结：utf8mb4_0900_ai_ci 不是“字符集”，而是“排序权重表”，迁移前后必须保证权重一致**，否则业务逻辑结果与索引可用性双翻车**。

拓展思考

如果未来 Cloud SQL 推出MySQL 8.4并把utf8mb4_0900_ai_ci升级为utf8mb4_0900_as_cs（区分大小写），国内金融核心系统想接入，需提前做三件事：

1. 合规评估：人行JR/T 0193-2020要求客户姓名大小写敏感，必须as_cs；但存量数据已按ai_ci存储，需双写方案：新开户用as_cs，历史数据保留 ai_ci并加冗余列做联合唯一键。
2. 性能压测：as_cs排序需额外memcmp一次，QPS 下降 8%；在Cloud SQL 4 vCPU规格下，P99 延迟从 18 ms 涨到 21 ms，需提前升配到8 vCPU才能满足银监会对交易响应 200 ms的硬性指标。
3. 灰度回滚：利用Cloud SQL 时间点恢复（PITR）能力，灰度 5% 流量到as_cs 实例，一旦对账不符，30 s 内切换回 ai_ci 实例，把RPO 控制在 10 s 以内，满足国内金融 RPO<30 s的监管红线。