MySQL 写入特殊字符报 Incorrect string value：列与连接都要支持 utf8mb4

MySQL 插入普通中文成功，写入某些表情或 Unicode 补充字符时却报 Incorrect string value，错误里的字节可能以 \xF0 开头。若失败列仍使用 utf8 或 utf8mb3，先检查它是否支持四字节字符，再检查应用连接的字符集。

这条路径适用于输入本来是合法 Unicode、目标列无法表示该字符的情况。Incorrect string value 也可能来自错误编码、连接声明与发送字节不一致，不能见到这个错误就转换整库。

utf8 名称不等于完整的 Unicode 支持

MySQL 的 utf8mb3 最多使用三个字节表示一个字符，不支持需要四字节 UTF-8 编码的补充字符。utf8mb4 支持这些字符，也能表示原来的基本多文种平面字符。MySQL 8.4 中 utf8 仍是已弃用的 utf8mb3 别名，因此只看到配置中写了 utf8，还不足以排除这个原因。

下面是报错形状示例，列名和字节用于说明，不代表每次失败都相同：

ERROR 1366: Incorrect string value: '\xF0\x9D\x8C\x86' for column 'body'

保留第一条错误、目标表列与应用使用的连接配置。不要只截取网页里显示成问号的字符；字符在入库前就被替换成 ? 时，数据库已经无法恢复原始内容。

查看实际列，不只看数据库默认值

在应用对应的实例与数据库执行以下只读检查。名称是示例，需要替换：

SELECT VERSION(), DATABASE();
SHOW CREATE TABLE appdb.messages;
SHOW FULL COLUMNS FROM appdb.messages;
SELECT @@SESSION.character_set_client,
       @@SESSION.character_set_connection,
       @@SESSION.character_set_results;

SHOW CREATE TABLE 与列信息用于确认失败列的字符集及排序规则。数据库默认字符集只影响相应的新对象；改了默认值，已有列不会自动全部转换。表级默认值同样不能代替对显式指定字符集的列进行检查。

三个会话变量分别涉及客户端发送、连接处理和结果返回。应在应用实际使用的连接上核对；另开一个命令行窗口显示 utf8mb4，不能证明连接池里的会话也是这个值。还要核对驱动把字符串按什么编码发送，不能只改服务器配置里的名称。

若目标列已经是 utf8mb4，但发送端仍声明 utf8mb3，先按所用驱动支持的方式配置连接字符集。若输入来自文件或外部接口，检查实际编码与解码过程；不能把任意二进制字节声明成 UTF-8，再期待数据库自动纠正。

列确实是 utf8mb3 时，安排可恢复的迁移

字符集修改属于结构变更。先备份目标数据与完整建表定义，在隔离副本上检查转换结果、索引限制、排序规则和应用查询，再安排正式迁移。

只需改变一列时，可以采用针对该列的 ALTER TABLE ... MODIFY，但必须保留完整类型、长度、是否允许 NULL、默认值及其他属性。不要把一个简化示例直接覆盖真实列定义。整表 CONVERT TO CHARACTER SET 会涉及其他字符列，某些类型还可能扩大，不能作为“只修一个字段”的等价操作。

选择排序规则也会影响比较、排序和唯一约束。原来不同的值，在新规则下可能被视为相等；有唯一索引时应先检查碰撞，而不是只验证能否存入一个表情。

字符集转换可能需要复制表、占用额外磁盘并阻塞操作，应按 MySQL 版本、存储引擎和表大小安排维护窗口。若已有字节使用了错误编码，正常字符集转换也可能损失数据；先识别错误编码的范围，不能把乱码批量转换当作修复。

迁移失败时，按已验证的备份和结构恢复方案回退。应用开始写入四字节字符后，再改回 utf8mb3 可能失败或损失新数据，因此不能把反向改字符集当作无条件撤销按钮。

连接与读回结果一起验收

列支持 utf8mb4 后，同步检查应用驱动及连接池初始化设置，按既有部署方式重建受影响连接。仅修改默认值，旧连接仍可能保留此前的会话字符集。

在隔离测试数据中，通过应用原来的写入路径保存包含普通中文与已知补充字符的字符串，再从同一路径读取并比较原值。成功标准是没有字符集转换错误、读回字符与输入完全一致，相关索引和业务查询仍符合预期。

若入库前已经产生问号或替代字符，这次结构修复不会恢复历史内容，需要从可靠原始数据补回。若新的失败改成包大小、索引长度或唯一约束错误，应按对应限制处理，不继续重复修改字符集。