MySQL存Emoji必须全链路使用utf8mb4，包括服务器、数据库、表、字段和连接层；任一环节为utf8（即utf8mb3）或未声明charset，INSERT就会报Incorrect string value错误。

MySQL 存 Emoji 不是“设成 utf8mb4 就完事”，而是全链路必须对齐——服务器、数据库、表、字段、连接层，任意一环卡在 utf8（即 utf8mb3）或未声明 charset，INSERT 就会报 Incorrect string value。

检查 MySQL 当前字符集链是否全为 utf8mb4

执行这两条 SQL，确认 6 项关键变量全部是 utf8mb4：

SHOW VARIABLES LIKE 'character\_set%';
SHOW VARIABLES LIKE 'collation%';

必须为 utf8mb4 的变量有：

• character_set_client
• character_set_connection
• character_set_database
• character_set_results
• character_set_server
• collation_server（推荐 utf8mb4_unicode_ci 或 utf8mb4_0900_as_cs）

character_set_system 固定为 utf8，可忽略；其余任一项是 utf8 或 latin1，说明配置未生效，或会话层被覆盖。

ALTER TABLE CONVERT TO CHARACTER SET utf8mb4 报错怎么办

常见错误是 Specified key was too long，因为 utf8mb4 单字符最多占 4 字节，而旧版 InnoDB 索引键限制为 767 字节。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

例如：VARCHAR(255) 加了索引 → 255 × 4 = 1020 字节 > 767 → 报错。

• 临时解法：把索引字段长度缩到 VARCHAR(191)（191 × 4 = 764，安全）
• 根治法：确认并启用 innodb_file_format=Barracuda、innodb_file_per_table=ON、innodb_large_prefix=ON，再加 ROW_FORMAT=DYNAMIC
• TEXT 类型字段不会随 CONVERT 自动升级，必须显式执行：
  MODIFY COLUMN content TEXT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci

应用连接层不配 charset=utf8mb4，前面全白干

即使表结构、服务端全设成 utf8mb4，只要客户端连接没声明字符集，MySQL 仍按默认（常为 latin1 或 utf8）解析字节流，Emoji 进来就是乱码或直接被截断。

• JDBC：jdbc:mysql://host:3306/db?useUnicode=true&characterEncoding=utf8mb4（注意：MySQL Connector/J ≥ 5.1.13；新版驱动不推荐硬写 characterEncoding，应依赖 init_connect + 自动探测）
• PHP PDO：mysql:host=localhost;dbname=test;charset=utf8mb4
• Node.js mysql2：{ charset: 'utf8mb4' }
• Django：OPTIONS={'charset': 'utf8mb4'} 必须显式写，ORM 不继承数据库全局设置

为什么 emoji 存进去了却显示为 ? 或乱码方块

这通常不是存储失败，而是读取时字符集错位。重点排查：

• 查询语句执行前，是否触发了 SET NAMES latin1 或其他非 utf8mb4 的会话级设置
• Web 服务（如 Nginx / Apache）是否强制设置了 Content-Type: text/html; charset=iso-8859-1 类响应头
• 前端 JS 用 fetch 或 AJAX 获取数据后，是否做了错误的 TextDecoder 编码转换
• 某些 ORM（如 SQLAlchemy）在建表时未透传 collation，导致字段实际仍是 utf8mb3，需手动 ALTER COLUMN

最易被忽略的是：连接层配置正确，但应用里某处动态拼接 SQL 时用了 SET NAMES utf8 ——这个 utf8 就是 utf8mb3，它会当场覆盖掉连接字符串里的 utf8mb4 设置。