utf8mb4 与 utf8 的区别：表情符号存不进去的真正原因

MySQL 里的 "utf8" 是 utf8mb3 的别名，最多只能存 3 个字节，而 emoji 这类字符在 UTF-8 编码下需要 4 个字节，所以它根本存不进去——报错 `Incorrect string value: '\xF0\x9F\x98\x80'` 里那个 `\xF0` 就是四字节序列的标志。结论：想存表情符号，必须把「服务端 + 数据库/表/列 + 连接」全部换成 utf8mb4，只改其中一层都不生效。

utf8mb3 和 utf8mb4 的真正差别是字节上限

UTF-8 是一种变长编码，按码点大小决定长度：U+0000–U+007F 占 1 字节，U+0080–U+07FF 占 2 字节，U+0800–U+FFFF 占 3 字节，U+10000 以上占 4 字节。MySQL 的 utf8mb3 把上限卡在了 3 字节，也就是只能覆盖 BMP（基本多文种平面，U+0000–U+FFFF）。

问题在于，emoji 全部落在 U+1F300–U+1FAFF 这类补充平面里，典型如 😀 = U+1F600，UTF-8 编码为 `F0 9F 98 80`，四字节。同理存不下的还有不少生僻汉字（如部分 CJK 扩展 B 区字）、彝文、部分音乐符号。而 utf8mb4 的 mb4 就是 "most bytes 4"，最多 4 字节，是真正的完整 UTF-8，能覆盖到 U+10FFFF。

顺带提醒：MySQL 8.0 里执行 `SHOW VARIABLES LIKE 'character_set%'` 会显示 `utf8mb3`，官方也已把它标记为弃用（deprecated），8.0 的默认字符集本来就是 utf8mb4，5.7 默认则是 latin1——如果你从 5.7 时代的老库升级上来，字符集问题几乎必然存在。

四个层级必须同时改，漏一层就白改

这是最常见的误区：只 `ALTER DATABASE` 是没用的，因为连接层的字符集决定了 MySQL 怎么解读你发过去的字节流。完整改动清单如下。

服务端配置（my.cnf）：

[mysqld]
character-set-server = utf8mb4
collation-server = utf8mb4_unicode_ci
[client]
default-character-set = utf8mb4

库和表：

ALTER DATABASE mydb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ALTER TABLE posts CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

连接层（PHP PDO 示例）：

$pdo = new PDO("mysql:host=localhost;dbname=mydb;charset=utf8mb4", $user, $pass);

注意 `charset=utf8mb4` 与 `SET NAMES utf8mb4` 等效。如果你的代码里写的是 `SET NAMES utf8`，那即使库表都是 utf8mb4，写入照样会出问题——连接层声称只支持 3 字节，MySQL 会把 4 字节序列截断或丢弃，表现为存进去变成 `?` 或空。

验证方法：

SHOW VARIABLES LIKE 'character_set%';
SHOW CREATE TABLE posts\G

重点看 `character_set_client`、`character_set_connection`、`character_set_results` 三项是否都是 utf8mb4，再确认表定义里没有残留的 `CHARSET=utf8`。

改完字符集最容易撞上的坑：索引 767 字节

结论：把列从 utf8 转成 utf8mb4 后，索引占用的字节数直接乘以 4/3，原本合法的索引可能超限报 `Specified key was too long`。

InnoDB 的索引前缀长度上限是 767 字节（COMPACT/REDUNDANT 行格式）或 3072 字节（DYNAMIC 行格式 + innodb_large_prefix）。经典翻车场景：`VARCHAR(255)` 建唯一索引，utf8mb3 下是 255×3 = 765 字节，刚好卡进 767；换成 utf8mb4 就变成 255×4 = 1020 字节，超了。

两个解决方向：一是把索引前缀缩短到 `VARCHAR(191)`（191×4 = 764 < 767），这也是当年各种框架把用户名/邮箱字段定成 191 的由来；二是确认行格式为 `ROW_FORMAT=DYNAMIC`，在 MySQL 5.7+ 上是默认值，这样可以用满 3072 字节。

还有一个隐蔽问题：排序规则混用。`utf8mb4_general_ci`、`utf8mb4_unicode_ci`、`utf8mb4_0900_ai_ci` 三者的比较和排序结果并不一致，跨表 JOIN 时如果两列排序规则不同，会直接报 `Illegal mix of collations`，或者让索引失效。建议全库统一，新建项目直接跟 MySQL 8.0 默认的 `utf8mb4_0900_ai_ci`，要跨 5.7/8.0 兼容就用 `utf8mb4_unicode_ci`。

迁移实操清单

• 先备份，`CONVERT TO CHARACTER SET` 会重建整张表，大表期间会锁写，挑低峰期做，或用 pt-online-schema-change / gh-ost 在线改。
• 列级字符集可能残留，用这条查漏：

SELECT table_name, column_name, character_set_name
FROM information_schema.columns
WHERE table_schema='mydb' AND character_set_name IS NOT NULL
AND character_set_name NOT LIKE 'utf8mb4%';

• 存储空间不用过度担心：`VARCHAR(N)` 里的 N 是字符数不是字节数，磁盘上按实际字节存储，纯中文英文的内容转成 utf8mb4 后体积不变，只是索引前缀按 N×4 估算。
• 已经被存成 `????` 或问号的旧数据无法恢复，原始字节在写入时就已经丢了，字符集转换救不回来。
• 应用层要配套：PHP 用 `mb_strlen` / `mb_substr` 而不是 `strlen` / `substr`，`htmlspecialchars` 显式传 UTF-8，正则加 `u` 修饰符。数据库和程序两边编码不一致，一样会出乱码。

最后区分一个容易混淆的场景：如果你用的是 Clara BBS 这类社区系统，普通用户发帖提示「图片上传/表情包是会员专属」，那是权限问题；而会员账号发 emoji 变成问号或报 `Incorrect string value`，才是本文说的字符集问题。两者症状相似，根因完全不同，先看后台设置再看数据库。

一句话收尾：utf8mb3 不是「阉割版 UTF-8」而是「三字节上限的 UTF-8」，emoji 存不进去是数学问题不是配置玄学；把服务端、库表列、连接四层统一到 utf8mb4，并注意索引前缀长度和排序规则一致，问题就彻底解决。