MySQL 8.0 升级后字符集自动变更为 utf8mb4，但旧表不会自动转换
这是最常被忽略的前提：MySQL 8.0 将
character_set_server和新建库/表的默认字符集从
latin1改为
utf8mb4，排序规则也变为
utf8mb4_0900_ai_ci。但所有已存在的数据库、表、列的字符集**完全保持原样**，不会因升级而改变。如果你的旧库是
latin1或
utf8（即 MySQL 5.x 常见配置），升级后它们仍是原编码——只是新连接默认用
utf8mb4，极易引发隐式转换和乱码。
常见错误现象：
• 应用插入中文或 emoji 后显示为问号或方块
•
SHOW CREATE TABLE显示表仍是
CHARACTER SET latin1，但客户端连接显示
character_set_client=utf8mb4
• 查询结果中部分字段正常、部分乱码，说明混用了不同字符集 务必先运行
SHOW VARIABLES LIKE 'character_set%';和
SHOW CREATE DATABASE db_name;确认当前实际设置 重点检查
character_set_database和具体表的
DEFAULT CHARSET，不要只看服务器变量 若发现
latin1表，必须主动迁移；
utf8表也建议升为
utf8mb4（因为 MySQL 的
utf8实际只支持 BMP 字符，不支持 emoji）
导出时必须指定原字符集，否则 dump 文件会二次编码
用
mysqldump迁移数据时，如果源库是
latin1，却用默认（或
--default-character-set=utf8mb4）导出，
mysqldump会把原本按
latin1存储的字节流，强行当作
utf8mb4解码再重新编码——导致每个中文变成 3–4 个乱码字节，导入后彻底不可逆。
正确做法：
导出前确认源表真实字符集：SHOW CREATE TABLE t1;→ 若含
CHARACTER SET latin1，导出命令必须加
--default-character-set=latin1示例：
mysqldump -u root -p --single-transaction --routines --triggers --hex-blob --default-character-set=latin1 mydb > dump.sql导入到 MySQL 8.0 新实例前，可先用
head -20 dump.sql | grep CHARSET检查 CREATE TABLE 语句里是否仍为
latin1；如需统一改，用
sed -i 's/CHARACTER SET latin1/CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci/g' dump.sql
ALTER TABLE CONVERT TO CHARACTER SET 不等于简单改声明
ALTER TABLE t1 CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci是最常用操作，但它不只是修改元数据——它会真正读取每一行数据，按原字符集解码、再按新字符集重新编码并写回。这意味着： 大表执行时会锁表（InnoDB 行锁，但 DDL 阶段仍可能阻塞写入），建议在低峰期操作，或使用
pt-online-schema-change在线变更 若原字段定义是
VARCHAR(255)且为
latin1，升级后实际能存的 UTF-8 字节数不变，但
utf8mb4下每个字符最多占 4 字节，可能导致索引超长报错：
ERROR 1071 (42000): Specified key was too long解决办法：提前缩减字段长度，或改用
innodb_large_prefix=ON（MySQL 5.7+ 默认开启）、
ROW_FORMAT=DYNAMIC执行后务必验证数据：
SELECT HEX(col), col FROM t1 WHERE col LIKE '%中文%' LIMIT 1;—— 正常应返回类似
E4B8ADE69687（UTF-8 编码），而非
C4E3BAC3（latin1 编码的乱码字节）
连接层必须显式声明 utf8mb4，不能依赖默认值
即使表和数据库都已是
utf8mb4，只要客户端连接没声明，依然会走默认字符集路径。MySQL 8.0 虽默认
character_set_client为
utf8mb4，但很多老应用或中间件仍用旧驱动，默认发
SET NAMES latin1或根本不设，导致服务端把收到的字节流错误解码。 应用连接字符串中必须显式加上
charset=utf8mb4（JDBC 用
useUnicode=true&characterEncoding=utf8mb4；PHP PDO 用
PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES utf8mb4"） 在 my.cnf 的
[client]和
[mysqld]段都配置：
default-character-set = utf8mb4和
character-set-server = utf8mb4关键防护项：
skip-character-set-client-handshake = ON—— 强制忽略客户端声明的字符集，只认服务端配置，避免被恶意或错误的
SET NAMES干扰
字符集迁移真正的难点不在 SQL 语句本身，而在全链路声明的一致性：数据怎么存的、元数据怎么写的、连接怎么连的、应用怎么编的——四者缺一不可。漏掉任意一环，就可能在某个特殊字符、某次批量导入、某个老旧接口里突然冒出乱码。
