MySQL的utf8不支持Emoji，根本原因是其最多只支持3字节编码，而Emoji属于Unicode辅助平面需4字节；必须将连接、数据库、表、列四级字符集均设为utf8mb4并调整索引长度才能完整支持。
MySQL 的 utf8 不支持 Emoji，根本原因是它最多只存 3 字节
MySQL 从 4.1 开始支持 utf8 字符集，但这个“utf8”是 MySQL 自己实现的精简版，不是 RFC 3629 定义的完整 UTF-8。它强制限制每个字符最多 3 字节，而 Emoji（如 ?、??、❤️?）和部分罕见汉字（如?、?）属于 Unicode 辅助平面，需要 4 字节编码。只要插入含这类字符的数据，就会报错：Incorrect string value: '\xF0\x9F\x98\x80' for column 'name' at row 1。
这不是客户端或连接层的问题，而是服务端存储层硬性截断——哪怕你把 character_set_client 和 character_set_connection 都设成 utf8mb4，只要表/列用的是 utf8，照样失败。
必须同时改这 4 个地方，utf8mb4 才真正生效
只改数据库或只改表是常见误区。MySQL 字符集生效是“连接 → 数据库 → 表 → 列”四级继承关系，任一环卡在 utf8 都会降级。实操中要确认并修改：
-
my.cnf中全局配置：character-set-server = utf8mb4+collation-server = utf8mb4_0900_ai_ci（MySQL 8.0+ 推荐） - 创建数据库时显式指定：
CREATE DATABASE db_name CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; - 已有表需逐列转换：
ALTER TABLE t MODIFY c VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; - 连接时强制指定：
SET NAMES utf8mb4;或在连接字符串里加?charset=utf8mb4
漏掉任意一项，比如只改了表但没改列的 COLLATE，某些排序或去重操作仍可能出错。
utf8mb4_unicode_ci 和 utf8mb4_0900_ai_ci 选哪个？
排序规则（collation）影响字符串比较、ORDER BY 和索引行为。旧版常用 utf8mb4_unicode_ci，但它基于较老的 Unicode 标准（UCA 4.0），对德语 ß、土耳其语 I/i 处理不够准。MySQL 8.0 引入的 utf8mb4_0900_ai_ci 基于 Unicode 9.0，支持大小写不敏感（ai）、口音不敏感（ci），且能正确处理更多语言边界情况。
除非你明确依赖旧版排序逻辑（比如 legacy 系统迁移），否则直接用 utf8mb4_0900_ai_ci。注意：它不兼容 MySQL 5.7 及更早版本，升级前务必验证。
字段长度和索引限制会变，VARCHAR(255) 可能不够用
utf8mb4 下，单个字符最多占 4 字节，而 utf8 最多 3 字节。InnoDB 的索引前缀限制是 767 字节（MySQL 5.6）或 3072 字节（5.7+，需 innodb_large_prefix=ON）。这意味着：
- 原来
VARCHAR(255)的字段，在utf8mb4下实际最多存 191 个四字节字符（767 ÷ 4 ≈ 191），否则建索引会失败 - 如果字段定义为
VARCHAR(255)并加了唯一索引，又存满 Emoji，很可能因截断导致重复值误判 - 解决方案：要么减小字段长度（如
VARCHAR(191)），要么改用TEXT类型并建函数索引（MySQL 8.0+）
这个限制不报错，只在建索引或插入超长数据时静默失败，容易被忽略。
