MySQL中建议使用utf8mb4，是因为它才是真正的、完整的UTF-8实现；而MySQL里叫utf8的字符集，实际是utf8mb3——最多只支持3字节编码，根本存不了emoji、某些冷门汉字、数学符号或古文字。
MySQL中建议使用utf8mb4，是因为它才是真正的、完整的UTF-8实现；而MySQL里叫utf8的字符集，实际是utf8mb3——最多只支持3字节编码，根本存不了emoji、某些冷门汉字、数学符号或古文字。
为什么utf8在MySQL里是个“伪UTF-8”
MySQL 5.5.3之前引入的utf8，是按当时Unicode 3.0标准设计的，只覆盖BMP（基本多文种平面），即U+0000–U+FFFF范围。它无法表示U+10000及以上的字符，比如：
-
?（U+1F60A）→ UTF-8编码为0xF0 0x9F 0x98 0x8A（4字节）→utf8直接报Incorrect string value - 古汉字「?」（U+23FE7）、数学符号「?」（U+1D306）同样会失败
- 很多越南语、阿拉伯语扩展字符也落在补充平面
这不是配置问题，是MySQL内部对utf8的硬编码限制：每个字符最多3字节，不可绕过。
从utf8mb4到utf8mb4_0900_ai_ci：默认值已变，但旧配置仍常见
MySQL 5.7起，character-set-server默认为utf8mb4；8.0.28+进一步将utf8别名标记为废弃，utf8mb3仅用于兼容性输出。但现实是：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 大量老实例仍在用
my.cnf里没改过的character-set-server=utf8（等价于utf8mb3） -
SHOW VARIABLES LIKE 'character_set%'查出character_set_server是utf8，说明没生效 - 即使服务器设了
utf8mb4，建库/表时没显式指定，仍可能继承旧默认或客户端设置
真正生效要三处一致：character-set-server + init_connect='SET NAMES utf8mb4' + 创建语句带CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci。
utf8mb4不是零成本：索引长度和存储开销需留意
启用utf8mb4后，VARCHAR(255)字段最大可能占用255×4=1020字节（而非utf8mb3下的765字节），这会影响：
- InnoDB单列索引长度上限是767字节（5.6及以前）或3072字节（5.7+ with
innodb_large_prefix=ON），超限会报Specified key was too long - 全文索引、前缀索引、联合索引的总长计算都基于字节数，不是字符数
- 内存临时表（
tmp_table_size）和排序缓冲区（sort_buffer_size）消耗略增
典型应对方式：VARCHAR(191)替代VARCHAR(255)（191×4=764
最常被忽略的一点：应用层连接参数往往没同步更新。PHP的mysqli_set_charset($conn, 'utf8mb4')、Python的charset='utf8mb4'、JDBC的useUnicode=true&characterEncoding=utf8mb4，漏掉任一环，utf8mb4就形同虚设——数据进得去，但客户端解码错乱或截断。
