MySQL 5.7 的 utf8 实为 utf8mb3，仅支持最多3字节UTF-8字符，无法存储emoji、部分生僻汉字等4字节字符，会导致静默截断或问号乱码；彻底解决必须全链路（服务端、数据库、表、连接层）统一升级至 utf8mb4。
直接结论：MySQL 5.7 中所谓“utf8截断字符”，本质是用了 utf8 字符集而非 utf8mb4 ——它最多只支持 3 字节编码，无法存储 emoji、部分生僻汉字（如“?”）、数学符号等 4 字节 UTF-8 字符。只要用 utf8，就一定会在插入或查询时被静默截断或转成问号。彻底规避的唯一路径是全链路切换到 utf8mb4，且不能漏掉任何一环。
为什么 MySQL 5.7 的 utf8 不是真正的 UTF-8
MySQL 5.7 的 utf8 是历史包袱：它实现的是 UTF-8 的子集（RFC 3629 前的旧规范），只允许 1–3 字节序列。而标准 UTF-8 允许 4 字节（U+10000 及以上），比如 ?（U+1F30D）、✅（U+2705）、䶮（U+2010E）。当你向 utf8 字段插入这些字符时：
- MySQL 会直接丢弃超出 3 字节的部分，不报错也不警告；
- 字段值看起来“少了一截”，比如 “Hello?” 存成 “Hello?”；
- 如果字段是
VARCHAR(10)，实际只存了 9 字节，但第 10 字节被截断后仍算作“合法长度”，不会触发data too long错误。
必须修改的四个层级（缺一不可）
只改表或只改配置，都会导致某一层仍用 utf8，引发隐式转换和截断。要全部对齐到 utf8mb4：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
character_set_server和collation-server：写入my.cnf的[mysqld]节点，重启生效； - 数据库级：
ALTER DATABASE db_name CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci;； - 表级：
ALTER TABLE tbl_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;（注意：CONVERT TO会重写所有字段，包括已有数据）； - 连接层：客户端连接字符串必须显式指定
charset=utf8mb4（如 JDBC 的useUnicode=true&characterEncoding=utf8mb4，C# 的charset=utf8mb4）。
生产环境不敢停库？先做兼容性检查再操作
直接执行 CONVERT TO 可能因索引长度超限失败（utf8mb4 单字符最多占 4 字节，原 utf8 索引最大长度 767 字节 → 实际最多支持 191 个字符）。需提前验证：
- 查哪些索引可能越界：
SELECT table_schema, table_name, column_name, character_maximum_length FROM information_schema.columns WHERE character_maximum_length > 191 AND data_type IN ('varchar', 'text') AND table_schema NOT IN ('mysql', 'information_schema');； - 对超长字段，要么缩减
VARCHAR长度，要么改用前缀索引（如INDEX(col_name(191))）； - 确认
innodb_large_prefix是否开启（MySQL 5.7 默认 ON），否则即使调小长度也可能报错； - 测试库先跑一遍
ALTER TABLE ... CONVERT TO，观察是否出现 Warning（如 “Data truncated”），有则说明历史数据里已存在被截断过的 4 字节字符，需人工清洗。
最容易被忽略的“连接层陷阱”
很多团队把服务端和表都改成 utf8mb4，却忘了客户端工具或 ORM 连接串仍是默认行为。典型表现：
- 命令行
mysql -u root -p连上去，INSERT含 emoji 的语句正常，但应用连进去就乱码或截断； - 原因是
mysql客户端默认读取[client]配置，而 Java 应用默认用latin1解析响应； - 必须显式加参数：
mysql --default-character-set=utf8mb4 -u root -p； - JDBC URL 示例：
jdbc:mysql://localhost:3306/db?useUnicode=true&characterEncoding=utf8mb4&serverTimezone=UTC； - PHP PDO 需在 DSN 中加
;charset=utf8mb4，且不能依赖SET NAMES utf8mb4（它只影响当前 session，不保证连接初始化时的 client encoding）。
真正麻烦的不是改配置，而是确认每一处连接——从监控脚本、定时任务、备份工具（如 mysqldump 默认用 utf8，必须加 --default-character-set=utf8mb4），到 DBA 手动排查用的 Navicat 或 DBeaver，全都得对齐。漏一个，就可能在某个凌晨三点往表里写进一个被截断的“?”字，然后花两天时间回溯源头。
