utf8mb4 在 MySQL 8.0 中并非性能更稳定，而是语义更正确：它完整支持 1–4 字节 Unicode 字符，避免 utf8（即 utf8mb3）对 emoji 等 4 字节字符报错或静默丢数据；其“稳定”源于确定性行为，而非性能提升，真正影响性能的是排序规则而非字符集本身。
MySQL 8.0 中 utf8mb4 并不比 utf8 “性能更稳定”——它只是更正确。所谓“更稳定”，其实是避免了 utf8（即 utf8mb3）在遇到 4 字节字符时直接报错或静默丢数据的不稳定行为。
utf8 在 MySQL 8.0 中根本不是真正的 UTF-8
你执行 CREATE TABLE t (c VARCHAR(10)) CHARACTER SET utf8;，MySQL 8.0 实际创建的是 utf8mb3 表。这个字符集只支持 Unicode BMP 平面（U+0000–U+FFFF），无法表示 emoji（如 ? 对应 U+1F60A）、某些生僻汉字（如 ?）、音乐符号（?）等。一旦插入这类字符：
- 可能触发
Incorrect string value: '\xF0\x9F\x98\x8A' for column 'c'报错 - 也可能被服务端静默截断或转成
?，造成原始数据永久丢失 - 应用层看到的是“有时成功、有时失败”的不可预测行为
utf8mb4 的“稳定”来自确定性行为
utf8mb4 支持完整的 Unicode（1–4 字节），所有合法 UTF-8 字符都能被接受、存储、原样读出。这种“稳定”不是性能指标提升，而是语义层面的可预期：
- 插入
INSERT INTO t VALUES ('??');不再报错，也不再变成问号 - 客户端连接参数
character_set_client、character_set_results和表字符集一致时，不会因隐式转换引发乱码 - 全文索引、正则匹配、
ORDER BY等操作基于真实字符而非截断后字节，逻辑一致
真正影响性能的是排序规则（collation），不是 utf8mb4 本身
很多人把 utf8mb4_unicode_ci 的排序开销误认为是 utf8mb4 的“性能代价”。其实：
-
utf8mb4_0900_ai_ci（MySQL 8.0 默认）比旧版utf8mb4_unicode_ci排序更快、更准 -
utf8mb4_bin性能最高，但区分大小写和重音，适合主键或唯一约束字段 - 如果只存 ASCII，utf8mb4 和 utf8mb3 存储空间差异几乎为零；混合中文/emoji 时，utf8mb4 单字符最多多占 1 字节，但这是必要代价
最容易被忽略的一点：连接层必须同步配置
即使表用了 utf8mb4，如果客户端连接没声明，照样出问题。必须确保三者一致：
- 建表语句含
CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci - 连接字符串带
?charset=utf8mb4（如 JDBC 的useUnicode=true&characterEncoding=utf8mb4） - MySQL 服务端变量
character_set_server建议设为utf8mb4，否则新库可能继承旧默认值
漏掉任意一环，utf8mb4 就会退化成“看起来用了，实则无效”的状态。
