只改数据库字符集再重新导入仍大概率报错，因ALTER DATABASE仅影响新建表，不修改已有表字段定义；且若mysqldump未加--default-character-set=utf8mb4或导入时未指定客户端字符集，CREATE TABLE语句仍沿用旧字符集，导致字段无法存储emoji等字符。
直接说结论：只改数据库字符集再重新导入，大概率还是会报错。 因为 ALTER DATABASE ... CHARACTER SET utf8mb4 只影响后续新建的表，默认不触碰已有表和字段的定义；而重新导入时，如果 mysqldump 没带 --default-character-set=utf8mb4，或导入命令没指定连接字符集，dump 文件里的 CREATE TABLE 语句仍会沿用旧的 CHARACTER SET utf8（即 utf8mb3），导致新表字段还是存不下 emoji 或生僻字。
为什么 mysqldump + 导入容易失败
常见错误现象：mysqldump db_name > backup.sql 导出后，mysql db_name 导入，插入含 ? 或 ?? 的数据仍报 <code>Incorrect string value。
- 默认导出不声明字符集，
backup.sql中的CREATE TABLE语句保留原字段的CHARACTER SET utf8 - 导入时若未显式设置客户端字符集（如没加
--default-character-set=utf8mb4），MySQL 会按character_set_client解析 SQL，可能退化为utf8 - 即使服务端已配
utf8mb4，导入过程中的字符集协商失败，会导致建表语句被错误解释
必须带参数导出 + 显式指定导入字符集
导出时强制使用 utf8mb4 编码生成 SQL：
mysqldump --default-character-set=utf8mb4 -u username -p db_name > backup.sql
导入时同样要声明客户端字符集，不能裸命执行：
mysql --default-character-set=utf8mb4 -u username -p db_name < backup.sql
注意两点：
-
--default-character-set=utf8mb4必须同时出现在导出和导入命令中，缺一不可 - 如果用
source backup.sql在 MySQL 客户端内执行，需先运行SET NAMES utf8mb4; - 导出前确认当前连接字符集是
utf8mb4：执行SHOW VARIABLES LIKE 'character_set_client';，值应为utf8mb4
比“重导”更稳妥的在线升级方案
对线上表，停服重导风险高、耗时长。推荐直接在库内逐层升级：
- 先改库：
ALTER DATABASE db_name CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci; - 再改表（仅影响后续新增列）：
ALTER TABLE tbl_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; - 最后精准改字段（最安全）：
ALTER TABLE tbl_name MODIFY COLUMN content TEXT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
关键点：
-
CONVERT TO会锁表并重建整张表，大表慎用；MODIFY COLUMN只改单字段，但必须重写完整定义（类型、NOT NULL、DEFAULT 等都不能丢） - 升级顺序不能跳：库 → 表 → 字段。跳过表级，字段即使改了，新插入数据仍可能因连接字符集未同步而失败
- 改完立刻验证：
SHOW CREATE TABLE tbl_name;看字段是否显示CHARACTER SET utf8mb4
真正容易被忽略的是应用连接层——就算数据库全配成 utf8mb4，只要 PHP/Python/Java 连接字符串里没写 charset=utf8mb4 或等效配置，character_set_client 就还是 utf8，照样报错。这个环节必须单独检查，不能依赖服务端配置。
