MySQL 8.4 默认字符集怎么迁移：utf8mb4、表级覆盖与连接握手核对

业务服务从 MySQL 5.7 升级迁移到 8.4 版本后，最容易漏掉的校验点从来不是“能不能正常存中文”，而是同一条查询在不同连接池实例里返回的排序结果不一致：表是 utf8mb4，连接却还沿用旧的字符集配置，应用读出来的中文显示完全正常，字符比较和排序逻辑其实已经偏离预期。整个迁移过程要把服务端默认值、库/表级定义、连接建立后的会话变量这三块分开逐一验收。

先理清四层默认值的关系：服务端配置不等于旧表配置

MySQL 的字符集规则是逐层覆盖生效的：服务端给出全局默认值，数据库级配置可以覆盖它，表和列级配置还能继续向上覆盖。MySQL 8.4 官方文档推荐优先使用 utf8mb4，同时明确说明 utf8 是已经被弃用的 utf8mb3 同义词。升级 MySQL 服务端版本不会自动替存量旧表重写字符集属性。

先把所有对象的存量状态查清楚再动手修改。直接批量替换通用建表脚本，很可能漏掉单独定义的列级 COLLATE，甚至让原本依赖旧排序规则的唯一索引触发重复键报错。

迁移前先做全量盘点：定位真正需要修改的表和列

下面的查询可以把表级定义和列级定义分开输出。表级结果用来判断整体迁移的范围，列级结果用来排查某个字段单独保留旧排序规则的特殊情况。

SELECT TABLE_SCHEMA, TABLE_NAME, TABLE_COLLATION
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'app_db'
  AND TABLE_TYPE = 'BASE TABLE'
ORDER BY TABLE_NAME;

SELECT TABLE_NAME, COLUMN_NAME, CHARACTER_SET_NAME, COLLATION_NAME
FROM information_schema.COLUMNS
WHERE TABLE_SCHEMA = 'app_db'
  AND CHARACTER_SET_NAME IS NOT NULL
ORDER BY TABLE_NAME, ORDINAL_POSITION;

把查询结果存成迁移前的基准快照，重点排查三类对象：

• 仍然使用 utf8mb3 的字符列，尤其是昵称、地址、备注这类可能存储四字节字符的字段。
• 同一张表内混用多个不同排序规则的列，这类字段做字符比较和排序时很容易触发隐式转换。
• 参与唯一索引、外键关联或者多表JOIN的字符列，这类列必须先准备代表性业务数据做测试验证。

如果业务场景必须保留某类特殊语言排序规则或者二进制排序规则，不用为了追求“全库统一”强行替换配置。迁移的目标是所有配置可解释、出问题可回退，不是所有库表对象的字符集都显示同一个名称。

表级转换怎么落地：先预演验证，再分批次执行

确认全量备份、锁等待影响、剩余索引空间都符合要求之后，再对单张表做字符集转换操作。下面的示例可以把表默认值切换到 utf8mb4 和 utf8mb4_0900_ai_ci：

ALTER TABLE orders
  CONVERT TO CHARACTER SET utf8mb4
  COLLATE utf8mb4_0900_ai_ci;

这条语句大概率会触发表或者索引的重建，执行前要结合线上MySQL版本和表的数据大小选合适的维护窗口。先在测试影子库完整跑一遍，记录执行耗时、临时空间占用、索引长度变化和可能的失败原因；线上环境按业务边界分批次执行，每张表转换完成后立刻做复查：

SHOW CREATE TABLE orders\G
CHECKSUM TABLE orders;
SELECT COUNT(*) FROM orders WHERE customer_name IS NOT NULL;

CHECKSUM TABLE 不是所有场景下的完整一致性校验依据，但可以作为迁移前后状态的快速确认信号。更关键的是要对包含中文、表情符号、大小写差异、重音字符的样本数据，做排序、唯一性校验、关联查询的回归测试。

连接握手是最后一公里：不要只看返回中文是否正常

MySQL 8.4 把服务端默认字符集设为 utf8mb4，不代表每一个客户端连接都已经按预期规则工作。连接建立完成后，用当前连接直接执行下面的检查操作：

SELECT
  @@character_set_client       AS client_charset,
  @@character_set_connection   AS connection_charset,
  @@character_set_results      AS results_charset,
  @@collation_connection       AS connection_collation,
  @@character_set_database     AS database_charset,
  @@collation_database         AS database_collation;

SET NAMES 会同时设置 client、connection、results 三个变量；如果附带 COLLATE，还会额外明确设置 connection 对应的排序规则。这个语句的作用范围只限于当前会话，所以连接池必须保证新连接创建和旧连接复用的环节，都执行同一套初始化配置逻辑。

SET NAMES 'utf8mb4' COLLATE 'utf8mb4_0900_ai_ci';
SELECT @@character_set_client,
       @@character_set_connection,
       @@character_set_results,
       @@collation_connection;

不能用“能正常插入一个中文”作为唯一验收标准。应用侧还要验证字符排序、条件比较、参数绑定、结果返回全链路逻辑；如果客户端声明了服务端不支持的字符集，连接配置还可能静默回退到服务端默认值，这类回退逻辑必须在日志或者连接健康检查里做显性暴露。

用验收清单收口：数据、排序、连接分别复查

1. 对象层：记录服务端、数据库、表和列的字符集/排序规则状态，确认没有遗漏的列级自定义配置。
2. 数据层：用四字节字符、中文混排、大小写差异、重音字符做写入、读取、模糊匹配和排序测试。
3. 连接层：在实际使用的驱动和连接池里读取四个会话变量，确认连接初始化后不会被旧配置覆盖。
4. 索引层：对唯一索引和关联查询条件做回归验证，重点排查转换后可能出现字符串值意外合并的情况。
5. 回退层：保留迁移前快照、对应DDL语句和单表恢复方案，遇到锁等待或者重复键报错先停止批量操作，避免影响范围扩散。

常见问题

MySQL 8.4 默认是 utf8mb4，旧表还需要转换吗？

要先做检查再判断。服务端默认值只会影响后续新建的对象，历史存量的表和列都会保留自己原本的定义；只有确认存量数据、索引和排序规则全部兼容后，再按表的优先级分批转换。

SET NAMES 和修改表排序规则是一回事吗？

完全不是。SET NAMES 只会修改当前连接的通信相关变量，表排序规则决定了列值存储和比较的默认行为，两个环节要分开做验收。

为什么返回中文正常，排序结果却不对？

结果能正常显示只说明字符编码转换没有直接报错，排序逻辑还会受到列排序规则、连接排序规则和隐式转换的多重影响，要检查 SHOW CREATE TABLE 和四个会话变量的配置。

能不能直接全库改成 utf8mb4_0900_ai_ci？

不建议直接执行全库替换操作。唯一索引冲突、业务特殊语言排序习惯、外键关联列一致性、大表锁等待这些因素都可能带来线上故障，应该先在影子库做完全量预演，再按表和索引的风险等级分批执行。

迁移的核心不是把配置文件里的字符集参数改成同一个值，而是让所有对象定义、真实存量数据、每条连接的握手结果三者完全匹配。把这三层核对完成，整个 utf8mb4 迁移才算真正落地。