MySQL 存表情报错怎么修改字符集

MySQL 插入 emoji、部分生僻字时出现 Incorrect string value，最常见的原因是链路中的某一层仍使用三字节的 utf8mb3：目标列放不下四字节字符，或者应用连接把请求按旧字符集发送。处理时不要只改数据库默认值，应先查清连接、数据库、表和列，再把需要写入表情的列与连接统一到 utf8mb4。

最快的判断方式是：先看 SHOW CREATE TABLE 中目标列是否为 utf8mb4，再看当前会话的 character_set_client、character_set_connection 和 character_set_results。两边有一边不是 utf8mb4，表情就可能在到达存储层前被拒绝。

先定位到底是哪一层不是 utf8mb4

字符集问题至少有四个观察面：客户端连接、当前数据库、表默认值和实际列定义。数据库默认值只是创建表时的继承来源，不能证明旧表已经改好。先在目标库执行下面的检查：

-- 查看当前连接、数据库和服务器的字符集
SHOW VARIABLES WHERE Variable_name IN (
  'character_set_client', 'character_set_connection',
  'character_set_results', 'character_set_database',
  'character_set_server'
);

-- 查看表默认值、列类型和列级字符集
SHOW CREATE TABLE user_message;
SELECT COLUMN_NAME, COLUMN_TYPE, CHARACTER_SET_NAME, COLLATION_NAME
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_SCHEMA = DATABASE()
  AND TABLE_NAME = 'user_message';

重点看保存正文或消息的 VARCHAR、TEXT 列。如果列是 utf8，在 MySQL 8.4 的信息中通常会显示为已弃用的 utf8mb3；如果连接变量仍是 utf8mb3，即使列已改好，客户端也可能在发送阶段失败。

把目标表转换为能存表情的字符集

对数据本身编码可信、且准备好备份的表，可以使用 CONVERT TO CHARACTER SET 同时转换表默认值和字符列：

-- 将消息表及其中的字符列统一到 utf8mb4
ALTER TABLE user_message
  CONVERT TO CHARACTER SET utf8mb4
  COLLATE utf8mb4_unicode_ci;

-- 转换后再次确认实际列定义
SHOW CREATE TABLE user_message;

排序规则要按版本和业务比较规则选择。MySQL 8.4 的 utf8mb4 默认排序规则是 utf8mb4_0900_ai_ci，旧环境或跨版本迁移时可以使用目标环境确实存在的兼容排序规则。不要为了“看起来统一”随意换排序规则，因为它会影响大小写、重音和唯一索引的比较结果。

还有一个容易被忽略的副作用：CONVERT TO CHARACTER SET 会按新字符集保证原有字符容量，某些 TEXT 或 VARCHAR 列可能被调整为更大的类型。若必须保持列类型不变，可改为逐列使用 MODIFY，并把原来的长度、是否允许为空、默认值和注释完整写回。

连接层也要改，否则表已经正确仍会报错

应用程序通过驱动建立连接时，应在连接参数中明确指定 utf8mb4。不同语言的参数名不同，但目标一致：客户端发送、服务端解释和结果返回都使用四字节字符集。临时排查可以执行：

-- 仅用于确认当前会话，不替代驱动的长期连接配置
SET NAMES utf8mb4;

-- 检查 SET NAMES 之后的会话状态
SHOW VARIABLES WHERE Variable_name IN (
  'character_set_client', 'character_set_connection',
  'character_set_results'
);

如果执行 SET NAMES utf8mb4 后插入成功，说明表结构大概率已经具备能力，问题更可能在连接池初始化或驱动配置没有持久化。生产代码应改连接配置，而不是每次业务写入前拼接 SQL；连接池重连、读写分离和迁移脚本都要使用同一套字符集约定。

可以用一条带表情的最小样例做回归：

-- 使用独立测试记录验证写入与读取
INSERT INTO user_message (content) VALUES ('编码检查 ✅ 🐘');
SELECT id, content, HEX(content) AS content_hex
FROM user_message
WHERE content = '编码检查 ✅ 🐘'
ORDER BY id DESC
LIMIT 1;

能读回完整表情只能说明这次链路成功，还要确认其他连接池、后台任务和导入脚本没有继续使用旧字符集。

这些变更边界要先排除

MySQL 官方特别提醒，字符集转换会尝试映射原有数据；如果列中存的是“用错误字符集解释出来的字节”，直接转换可能造成二次损坏。大表还要关注锁、重建时间和备份恢复路径，先在相同版本的预发布库演练，再安排窗口。

常见问题

为什么把数据库改成 utf8mb4，旧表还是不能存表情？

数据库默认值主要为创建新表提供继承值，已经存在的表和列不会自动重写。请以 SHOW CREATE TABLE 和 INFORMATION_SCHEMA.COLUMNS 的实际结果为准。

MySQL 里的 utf8 和 utf8mb4 有什么区别？

在 MySQL 中，历史上的 utf8 是 utf8mb3 的别名，最多三字节；utf8mb4 最多四字节，能表示补充平面字符，因此更适合新应用。

一定要把整张表都改成 utf8mb4 吗？

不一定。只有需要保存表情或其他补充字符的列必须具备相应能力，但表默认值、相关索引列和应用连接应形成清楚的一致性边界。对遗留表可以先改目标列，再按依赖逐步扩大范围。

相关事实可参考 MySQL 的 utf8mb4 字符集说明、ALTER TABLE 字符集转换说明。真正上线前，把表结构、连接池、索引和回滚脚本作为一个变更单一起评审。