应用写入中文、emoji或特殊符号时，MySQL返回Incorrect string value。即使数据库默认字符集已经改成utf8mb4，旧表、旧列或当前连接仍可能使用其他字符集。
MySQL字符集存在多个层级，修改server默认值不会自动重写已有列。
错误1366说明了什么
MySQL官方FAQ用无法表示目标字符的示例说明错误1366：输入字符不在目标列字符集的可表示范围内。严格模式下写入会失败；非严格模式可能产生警告并替换字符。
不要通过关闭严格模式换取写入成功，这可能把原字符永久存成问号或截断值。
从列定义开始检查
执行SHOW CREATE TABLE 表名，并查询information_schema.columns确认出错列的character_set_name与collation_name。数据库或表默认值是新列的默认来源，已有列可能仍保留latin1、utf8mb3或其他字符集。
以列的实际定义为准，不要只看character_set_server。
核对客户端连接与真实字节
查看character_set_client、character_set_connection和character_set_results，确认驱动连接参数明确使用utf8mb4。对测试值使用HEX()核对字节，区分输入本身已损坏与服务器转换失败。
不要在生产日志记录完整密码、令牌或个人文本。仅记录必要的编码信息和脱敏样例。
安全迁移到utf8mb4
先备份结构与数据，在同版本副本测试ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4对索引长度、行大小、排序规则和锁的影响。大表迁移可能重建表并占用额外空间，应安排维护窗口或合适的在线变更方案。
应用连接、表和列要一起修改。只改其中一层会留下间歇性错误。
怎样确认修复完成
用包含中文、emoji与补充平面字符的脱敏样例完成写入和读回，再比较HEX()与原始字节。可在萤光云或LightNode的测试VPS演练迁移。验收标准是字符完整往返、无1366警告、旧数据未乱码且索引和查询结果符合预期。
FAQ
问：MySQL里的utf8就是utf8mb4吗？答：在MySQL 8.4中utf8仍是utf8mb3的弃用别名，完整四字节Unicode应明确使用utf8mb4。
问：只执行SET NAMES utf8mb4可以吗？答：它只能调整当前连接相关字符集，目标列若仍不支持该字符，写入依旧失败。
温馨提示
温馨提示：字符集迁移前先盘点所有列和连接驱动。对消息队列、导入脚本与定时任务也要同步更新，避免主应用修复后仍由旧客户端写入错误字节。
