MySQL服务端默认字符集必须设为utf8mb4，需在my.cnf/my.ini的[mysqld]段配置character-set-server和collation-server并重启；客户端连接须显式声明charset=utf8mb4；已有表转换需先收缩索引字段再执行CONVERT TO；验证须同时检查连接层、存储层和数据层。
MySQL服务端默认字符集必须设为utf8mb4
很多乱码问题根源不在应用层，而在MySQL启动时根本没加载正确的字符集。只改表或字段的CHARACTER SET没用——如果服务端默认还是latin1或utf8（MySQL里的utf8其实是阉割版，不支持emoji和部分生僻中文），新连接一上来就继承错误编码。
实操上要改my.cnf或my.ini，在[mysqld]段落强制指定：
[mysqld] character-set-server = utf8mb4 collation-server = utf8mb4_unicode_ci
注意：collation-server不能漏，否则排序和比较行为可能异常；改完必须重启MySQL服务，SET GLOBAL临时生效无效。
- Linux下配置文件通常在
/etc/my.cnf或/etc/mysql/my.cnf - Windows下找
my.ini，位置可能是C:\ProgramData\MySQL\MySQL Server X.X\ - 改完用
mysql --verbose --help | grep "Default charset"确认是否生效
客户端连接时显式声明charset=utf8mb4
即使服务端设对了，PHP、Python、Java这些客户端如果不主动申明，仍可能走默认编码（比如MySQL JDBC驱动旧版本默认用latin1）。乱码常出现在“写入正常、查出来是问号”这种场景。
不同语言写法差异大，但核心都是在连接字符串或初始化参数里塞charset=utf8mb4：
- PHP PDO：
$pdo = new PDO("mysql:host=localhost;charset=utf8mb4", ...) - Python PyMySQL：
charset="utf8mb4"传进connect() - Java JDBC：
jdbc:mysql://localhost:3306/db?characterEncoding=utf8mb4 - Node.js mysql2：
charset: 'UTF8MB4_GENERAL_CI'（注意大小写和下划线）
别信“自动检测”，MySQL不猜编码，它只认你声明的值。
已有表和字段批量转成utf8mb4的稳妥步骤
直接ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4容易翻车——如果字段有全文索引、外键约束、或者列宽超限（utf8mb4单字符最多占4字节，原varchar(255)在utf8mb4下可能超出index key length限制），会报错ERROR 1071 (42000)。
安全做法分三步走：
- 先检查：用
SHOW CREATE TABLE `table_name`看当前定义和索引长度 - 再收缩：如果字段是
varchar(255)且带索引，先ALTER TABLE ... MODIFY column_name VARCHAR(191)（因为InnoDB默认最大索引长度767字节，767÷4≈191） - 最后转换：
ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci
特别注意：CONVERT TO会重写整张表，大表务必在低峰期操作，否则锁表时间很长。
验证是否真生效：三个地方缺一不可
很多人只查SHOW VARIABLES LIKE 'character_set%'，这只能证明服务端设对了，不代表数据真按utf8mb4存。必须同时确认：
- 连接层：
SHOW VARIABLES LIKE 'character_set_client'和'character_set_connection'都得是utf8mb4 - 存储层：
SHOW CREATE TABLE table_name看建表语句里字段是否带CHARACTER SET utf8mb4 - 数据层：用
SELECT HEX(column_name) FROM table_name LIMIT 1查中文字段，如果是4字节十六进制（如E4B8AD代表“中”），说明存对了；如果是2字节（如D6D0），说明还是老gbk或latin1编码
最常被忽略的是连接层——应用连上去了，但用的是旧连接池配置，实际走的还是latin1通道。
