直接执行 ALTER TABLE t CONVERT TO CHARACTER SET utf8mb4 会导致中文变问号或 Mojibake，因 MySQL 错误地按旧字符集解码字节再用新字符集编码；安全转换需先确保列定义字符集与实际存储字节一致，再分两步修正元数据和升级编码。
ALTER TABLE 修改字符集时为什么数据会乱码
直接执行 ALTER TABLE t CONVERT TO CHARACTER SET utf8mb4 很可能让原有中文变问号或 Mojibake，根本原因是 MySQL 在「转换」过程中默认按旧字符集重新解释字节，再用新字符集编码——如果原字段实际存的是 utf8（即 utf8mb3）编码的字节，而表/列定义却是 latin1，MySQL 就会错误地把那些字节当 latin1 解码成 Unicode，再存成 utf8mb4，一步错步步错。
真正安全的前提是：当前列中存储的字节，与列定义的字符集一致。不满足这点，先别动 CONVERT。
确认当前字符集与真实编码是否匹配
查三处关键信息比对：
- 表默认字符集：
SHOW CREATE TABLE t看DEFAULT CHARSET - 字段定义字符集：
SHOW FULL COLUMNS FROM t看Collation列（如utf8mb4_unicode_ci表示字段用utf8mb4） - 实际内容编码：用十六进制导出几条含中文的记录，比如
SELECT HEX(content) FROM t LIMIT 1，对照判断——utf8mb3下“李”是E69D8E，latin1下误存则可能是C3A6C29DC28E（双编码污染）
如果 Collation 是 latin1_swedish_ci，但 HEX() 显示的是三字节 UTF-8 编码，说明数据是 UTF-8 字节、元数据却标错了——这是最常见乱码根源。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
安全转成 utf8mb4 的两步法（不丢数据）
核心原则：先修正元数据（不改字节），再真正转换编码。不能一步到位。
- 第一步：把列字符集「声明」为当前真实编码（例如真实是
utf8mb3字节，但定义是latin1），用MODIFY COLUMN强制重定义，不转换内容：ALTER TABLE t MODIFY COLUMN content VARCHAR(255) CHARACTER SET utf8mb3 COLLATE utf8mb3_unicode_ci; - 第二步：再升级到
utf8mb4，此时字节和元数据一致，CONVERT才安全：ALTER TABLE t CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; - 注意：如果字段有索引且长度超 767 字节（如
VARCHAR(255)+utf8mb4），需提前设innodb_large_prefix=ON并用BARRACUDA文件格式，否则ALTER会报错Specified key was too long
修改后必须验证的三个点
改完不是就结束了，立刻检查：
- 连上客户端时是否带
?charset=utf8mb4（如 JDBC URL 或 Pythoncharset='utf8mb4'），否则 SELECT 出来还是乱码 - 执行
SELECT content, HEX(content) FROM t LIMIT 1，确认中文对应的 HEX 值是合法的四字节序列（如 ? 是F09F8C8F），且不再是重复的双编码痕迹 - 写入新 emoji（如 ?）再读取，看是否原样返回；若存成 或被截断，说明客户端或连接层没切到
utf8mb4
最易忽略的是连接层配置——表和字段全改成 utf8mb4 了，但应用仍用 utf8 连接，等于白改。
