mysql 8.0创建数据库必须显式指定character set utf8mb4和collate utf8mb4_unicode_ci，否则默认沿用latin1导致中文或emoji插入报错；旧库升级后字符集不自动变更，需逐表执行convert to；连接层三变量（client/connection/results）也必须统一为utf8mb4才能避免乱码。
创建数据库时必须显式指定字符集，否则默认用 latin1
MySQL 8.0 之前默认字符集是 latin1，哪怕系统变量 character_set_server 设为 utf8mb4，新建库仍可能沿用旧默认值。不指定就等于埋雷——后续插入中文会报 Incorrect string value 错误，或者存进去乱码但查不出来问题。
正确做法是创建时直接写死字符集和校对规则：
CREATE DATABASE mydb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
-
utf8mb4是真正支持 4 字节 Unicode（如 emoji、生僻汉字）的字符集，utf8在 MySQL 里只是utf8mb3的别名，不推荐 -
utf8mb4_unicode_ci比utf8mb4_general_ci排序更准确，MySQL 8.0+ 默认也用它 - 如果项目明确要求大小写敏感，可用
utf8mb4_0900_as_cs（MySQL 8.0+）
查看已建数据库的字符集，别只信 SHOW CREATE DATABASE
SHOW CREATE DATABASE mydb 看到的 CHARACTER SET 是建库语句里的声明，但实际生效的还得看当前连接和表级设置。真正决定数据存储行为的是表的字符集，而表又继承自库——所以得确认三层是否一致。
查库级字符集最稳的方式是：
SELECT DEFAULT_CHARACTER_SET_NAME, DEFAULT_COLLATION_NAME FROM information_schema.SCHEMATA WHERE SCHEMA_NAME = 'mydb';
- 如果返回
utf8mb4和utf8mb4_unicode_ci，说明库本身没问题 - 但若之后建表没指定字符集，且 MySQL 配置里
collation_server是latin1_swedish_ci，那表还是会变成latin1 - 建议在建库后立刻执行
USE mydb;，再检查SELECT @@character_set_database, @@collation_database;
MySQL 5.7 升级到 8.0 后，老库字符集不会自动升级
升级后 SHOW VARIABLES LIKE 'character_set%' 全是 utf8mb4，但已有数据库的字符集不变。新创建的库会按新默认值走，老库仍维持原样——包括里面所有表和字段。
- 不能只改库的字符集元数据：执行
ALTER DATABASE mydb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;只影响后续新建表，不改变已有表 - 要彻底迁移，得逐个表执行
ALTER TABLE t CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; - 注意：
CONVERT TO会重建表，大表慎用；如果字段有ENUM或SET，需额外处理排序规则兼容性
客户端连接不配对，设了 utf8mb4 也白搭
数据库、表、字段全设成 utf8mb4，但客户端连接用 latin1，照样存乱码。关键在连接层的三要素：客户端字符集、连接字符集、结果字符集。
- 连接时显式指定：
mysql --default-character-set=utf8mb4 -u root -p mydb - 应用代码里（如 Python PyMySQL）必须加参数：
charset='utf8mb4'，不能只写utf8 - PHP PDO 要在 DSN 加
;charset=utf8mb4，且不能依赖SET NAMES utf8（它不设utf8mb4） - 检查连接实际生效值：
SELECT @@character_set_client, @@character_set_connection, @@character_set_results;三个都应是utf8mb4
字符集不是“设一次就完事”的配置，它是从建库、建表、连库、写入、查询整条链路都要对齐的事。最容易漏掉的是连接层，而且出问题时现象模糊——看着 SQL 没报错，但 SELECT 出来是问号或 Mojibake。
