mysql 8.0新建实例默认utf8mb4，但需显式声明character set和collate、启用row_format=dynamic与innodb_large_prefix、连接层配charset=utf8mb4，否则超长emoji仍报错或转为???。
MySQL 8.0 新建实例默认已是 utf8mb4，但“默认支持”不等于“开箱即用”——只要没显式指定 COLLATE、没启用大前缀支持、连接层未对齐，超长 emoji（如 ?✨??）仍会触发 Incorrect string value 或静默转成 ???。
新建库时必须显式声明 CHARACTER SET 和 COLLATE
MySQL 8.0 的 character_set_server 默认是 utf8mb4，但新 CREATE DATABASE 语句若不写明字符集，可能继承旧配置或依赖 session 变量，极不稳定。尤其在自动化部署脚本中，遗漏声明等于埋雷。
- 错误写法：
CREATE DATABASE mydb;—— 依赖当前会话的character_set_database，不可控 - 正确写法：
CREATE DATABASE mydb CHARACTER SET = utf8mb4 COLLATE = utf8mb4_0900_as_cs;（推荐_0900_as_cs，区分大小写且更准；_0900_ai_ci也可，但对 emoji 排序无实质影响） - 验证：执行
SELECT DEFAULT_CHARACTER_SET_NAME, DEFAULT_COLLATION_NAME FROM INFORMATION_SCHEMA.SCHEMATA WHERE SCHEMA_NAME = 'mydb';，两项必须明确返回utf8mb4和对应 collation
CREATE TABLE 必须每字段级指定 CHARACTER SET
即使库级设对了，表定义里字段若留空或硬写 utf8，MySQL 会优先信任字段定义。而超长 emoji 常出现在 VARCHAR 或 TEXT 字段，一旦字段级没锁死 utf8mb4，插入就会失败。
- 危险写法：
content TEXT—— 字段未声明字符集，可能沿用表默认（未必可靠）或 server 默认（可能被覆盖） - 安全写法：
content TEXT CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_as_cs - 索引字段要额外注意：
VARCHAR(255)加索引在utf8mb4下最多占 1020 字节（255×4），超过 InnoDB 默认 767 字节限制 → 报Specified key was too long。要么缩为VARCHAR(191)，要么确保表启用了ROW_FORMAT=DYNAMIC和innodb_large_prefix=ON
连接层不配 charset=utf8mb4，前面全白干
新建库和表再完美，客户端连进来时用的是 latin1 或 utf8 握手，MySQL 就按那个字符集解析字节流——4 字节 emoji 被截断或误判，根本到不了存储层。
- PHP PDO：
mysql:host=localhost;dbname=mydb;charset=utf8mb4（charset是 DSN 键，不是 query 参数） - JDBC：
jdbc:mysql://localhost:3306/mydb?useUnicode=true&characterEncoding=utf8mb4，且驱动版本 ≥ 8.0.28（低版本对_0900collation 支持不稳） - 命令行客户端：
[client]段必须加default-character-set = utf8mb4，否则mysql -u root -p连进去仍是utf8解析 - 验证连接是否生效：
SHOW VARIABLES LIKE 'character_set_client';和character_set_results必须都是utf8mb4
超长 emoji 存储真正卡点在 ROW_FORMAT 和 innodb_large_prefix
单个 emoji 如 ?（U+1F308）是 4 字节，但组合型 emoji 如 ??（family + zero-width joiner）可达 10+ 字节。这类超长序列在 VARCHAR 中易突破单行限制，而 MySQL 8.0 默认 ROW_FORMAT=Dynamic，但老配置或迁移环境可能残留 COMPACT。
- 检查当前表格式：
SHOW CREATE TABLE mytable;看末尾是否有ROW_FORMAT=DYNAMIC - 强制启用：
ALTER TABLE mytable ROW_FORMAT=DYNAMIC; - 确认全局参数：
SELECT @@innodb_large_prefix;必须为ON（MySQL 8.0 默认是 ON，但某些云数据库托管实例会重置） - 别信“CONVERT TO”万能：
ALTER TABLE t CONVERT TO CHARACTER SET utf8mb4不改ROW_FORMAT，也不动已存在的TEXT字段编码，必须配合MODIFY COLUMN显式重申
最容易被忽略的是：即使所有配置都对了，如果应用在连接后执行了 SET NAMES utf8 或 SET character_set_client = utf8，会当场覆盖握手结果——这种动态设置比配置文件还优先，排查时得翻完整 SQL 日志。
