MySQL 8.0升级后默认字符集变为utf8mb4，但旧表字符集保持不变；需手动迁移latin1/utf8表，导出时须指定源字符集，ALTER TABLE CONVERT会重编码数据，连接层必须显式声明utf8mb4。
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 语句本身，而在全链路声明的一致性：数据怎么存的、元数据怎么写的、连接怎么连的、应用怎么编的——四者缺一不可。漏掉任意一环，就可能在某个特殊字符、某次批量导入、某个老旧接口里突然冒出乱码。
