MySQL插入Emoji报错“Incorrect string value”的直接原因是字段或表字符集仍为utf8（utf8mb3），仅支持3字节，而Emoji需4字节；必须同步配置服务端、数据库、表/列、客户端连接四层为utf8mb4，缺一不可。
MySQL插入Emoji报错：Incorrect string value
直接原因是字段或表的字符集仍是utf8（即utf8mb3），它最多只支持3字节Unicode字符，而Emoji普遍需要4字节（如?、?）。MySQL的utf8不是真正的UTF-8，这是历史遗留坑。
必须把涉及存储Emoji的字段、表、连接、服务端全部升级到utf8mb4，缺一不可。只改表或只改字段，仍会触发Incorrect string value错误。
- 常见错误信息：
Incorrect string value: '\xF0\x9F\x98\x8A' for column 'content' at row 1 -
\xF0\x9F\x98\x8A是?的UTF-8四字节编码，utf8mb3无法解析 - 即使客户端发的是正确UTF-8字节，MySQL在server层或column层截断/拒绝也会报错
必须同步修改的4个层级
只改其中一两个层级，Emoji仍会丢、报错或显示为问号。顺序不重要，但必须全部到位：
-
服务端默认字符集：修改
my.cnf（Linux）或my.ini（Windows），在[mysqld]下加：[mysqld] character-set-server = utf8mb4 collation-server = utf8mb4_unicode_ci
-
数据库创建时指定：
CREATE DATABASE db_name CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; -
表与字段显式声明：
ALTER TABLE comments CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;或对单字段：MODIFY content TEXT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; -
客户端连接时指定编码：应用代码中必须设置连接参数，例如PHP PDO：
new PDO($dsn, $user, $pass, [PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES utf8mb4"])；Java JDBC URL加?characterEncoding=utf8mb4
验证是否真正生效的3个检查点
别只看SHOW CREATE TABLE——它可能显示utf8mb4，但连接层或服务端没配对，照样失败。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 查服务端全局变量：
SHOW VARIABLES LIKE 'character_set%';确保character_set_server和collation_server是utf8mb4 - 查当前连接编码：
SHOW VARIABLES LIKE 'character_set_client';和character_set_connection也必须是utf8mb4 - 查字段实际定义：
SHOW FULL COLUMNS FROM table_name;看Collation列是否为utf8mb4_unicode_ci（不是utf8_general_ci）
只要任一环节是utf8或latin1，Emoji就不可靠。
utf8mb4带来的额外注意点
升级后不是万事大吉，有2个现实约束容易被忽略：
-
索引长度限制变严：InnoDB单列索引最大767字节（老版本）或3072字节（5.7+ with
innodb_large_prefix=ON）。utf8mb4下，一个VARCHAR(255)字段理论最大占1020字节（255×4），超长字段建索引会失败。建议：短文本用VARCHAR(191)起步，或确认innodb_large_prefix已启用 -
排序规则影响查询行为：
utf8mb4_unicode_ci比utf8mb4_general_ci更准（已弃用），但性能略低；若需大小写敏感，得用utf8mb4_bin，但WHERE name = 'Apple'将不匹配'apple'
Emoji能存进去只是第一步，后续全文检索、ORDER BY、JOIN的隐式转换都依赖统一且正确的utf8mb4上下文，漏掉任意一层，问题都会在某个凌晨三点复现。
