MySQL 8.0 默认用 utf8mb4 是因旧 utf8（即 utf8mb3）仅支持 3 字节 Unicode，无法存储 Emoji 等 4 字节字符，插入必报 Incorrect string value；utf8mb4 才是完整 UTF-8 实现，自 5.5.3 存在，8.0 仅设为默认。
MySQL 8.0 默认用 utf8mb4，不是为了“更好看”或“更时髦”，而是因为旧的 utf8（实际是 utf8mb3）根本存不了 Emoji 和大量现代 Unicode 字符——一插就报 Incorrect string value，这是硬性限制，不是配置没调好。
为什么 utf8 在 MySQL 里存不了 ?❓
MySQL 的 utf8 是个历史别名，最多只支持 3 字节编码，对应 Unicode 基本多文种平面（BMP）。而 Emoji、部分生僻汉字（如 U+20000 起的扩展 C/D/E 区）、甚至某些数学符号，都落在辅助平面，需 4 字节编码。
-
\xF0\x9F\x92\x95（?）这类字节序列在utf8下直接被截断或拒绝 -
SHOW CHARSET LIKE 'utf8'显示的 Maxlen 是 3，不是 4 - 从 MySQL 8.0.28 起，
utf8已被官方标记为「已弃用」
utf8mb4 要生效，光改 server 变量远远不够
只在 [mysqld] 里设 character-set-server = utf8mb4，只会让新库默认用对；已有表、字段、连接仍可能卡在 latin1 或 utf8 上。
- 逐层检查：
SELECT DEFAULT_CHARACTER_SET_NAME FROM INFORMATION_SCHEMA.SCHEMATA WHERE SCHEMA_NAME = 'db_name'; - 查字段级定义：
SELECT TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME, CHARACTER_SET_NAME, COLLATION_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE CHARACTER_SET_NAME IN ('latin1', 'utf8'); - 改表必须带
COLLATE，否则可能意外切换成utf8mb4_0900_ai_ci，导致大小写行为突变
改完 utf8mb4，索引和建表容易静默失败
VARCHAR(255) 在 utf8mb4 下理论最大占 1020 字节，超过 InnoDB 默认的 767 字节单列索引上限，会报 Specified key was too long。
- 必须确保：
innodb_file_format = Barracuda、innodb_file_per_table = ON、innodb_large_prefix = ON - 建表或转换时显式指定：
ROW_FORMAT = DYNAMIC - 漏掉任一条件，
ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4可能看似成功，但字段实际仍是utf8编码
JDBC 连接不声明 charset=utf8mb4，服务端配得再对也白搭
即使数据库、表、字段全设成 utf8mb4，Java 应用仍报 Incorrect string value，八成卡在连接参数上。
- JDBC URL 必须加：
?useUnicode=true&characterEncoding=utf8mb4 - 驱动版本要 ≥ 5.1.13（老驱动会把
utf8mb4当作未知字符集降级处理） -
init_connect='SET NAMES utf8'在 8.0 下会被映射为utf8mb4，但这只影响连接层，不改变字段定义
真正支持 Emoji 不是改一个配置的事，是数据库层、表结构层、字段定义层、连接层四层全部对齐；任何一层掉链子，都会在插入时突然报错，而且错误信息不会告诉你哪一层错了。
