character-set-server 配置必须为 utf8mb4 且需与客户端、连接层、表结构对齐；仅设此项不够，还需同步配置 collation-server=utf8mb4_unicode_ci，重启服务后验证生效，并补全数据库、表及客户端连接的 utf8mb4 设置。
character-set-server配置不对，是 MySQL 中文乱码最常见、也最容易被忽略的根源。它不等于“只要设成 utf8 就万事大吉”，而是必须和客户端、连接层、表结构三者对齐，否则插入或查询时仍会出错。
为什么只改 character-set-server 不够？
MySQL 有至少 6 个字符集变量：character_set_client、character_set_connection、character_set_database、character_set_results、character_set_server、character_set_system。其中 character-set-server 只控制 character_set_server 和新建数据库的默认值，但不影响已存在的库、表、字段，也不影响客户端连接时的实际编码协商。
常见错误现象：
- 插入中文报
Incorrect string value: '\xE6\x88\x91' for column 'name' at row 1 -
show create table显示表字符集是latin1，哪怕character_set_server已是utf8 - 命令行能插中文，但 Java/Python 程序插进去变成问号或乱码
如何正确配置 character-set-server 并确保生效？
在 my.cnf（Linux）或 my.ini（Windows）中，[mysqld] 段必须同时设置以下两项（缺一不可）：
-
character-set-server=utf8mb4（不是utf8） -
collation-server=utf8mb4_unicode_ci（推荐，比utf8mb4_general_ci更准确）
注意：utf8 是 MySQL 的历史别名，实际等价于 utf8mb3，不支持 emoji 和部分 Unicode 字符；utf8mb4 才是真正的 UTF-8 实现。
配置后必须重启 MySQL 服务（systemctl restart mysql 或 net stop mysql && net start mysql），再执行：
mysql> show variables like 'character_set_server';
确认输出值为 utf8mb4。如果仍是 utf8，说明配置文件没被加载，或写在了错误的 section（比如写进了 [client]）。
光配 character-set-server 还会漏掉哪三处？
即使 character_set_server 正确，以下三处不一致照样导致乱码：
-
已有数据库：用
ALTER DATABASE db_name CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci; -
已有数据表：用
ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; -
客户端连接层：程序连接时显式指定字符集，例如 JDBC URL 加
?characterEncoding=utf8mb4，Pythonpymysql.connect(..., charset='utf8mb4')
特别注意：CONVERT TO 会重写所有字段定义，包括 TEXT、VARCHAR 长度限制（如 VARCHAR(255) 在 utf8mb4 下实际最多存 63 个 emoji），上线前务必验证字段容量是否足够。
为什么建议跳过 set names utf8mb4 这种临时方案？
这条命令只在当前会话生效，且只设置 character_set_client、character_set_connection、character_set_results 三个变量，无法解决表结构或数据库本身的编码问题。它适合调试，但不能用于生产环境。
容易踩的坑：
- 误以为执行了
set names utf8mb4就一劳永逸，结果第二天新连接又乱码 - 在存储过程中执行该语句，但过程内未显式指定字符集，导致内部字符串处理仍按默认规则转码
- 客户端本身编码是 GBK（如 Windows CMD），却硬设
set names utf8mb4，反而引发二次转码错误
真正稳定的做法，是让服务端配置、建库建表脚本、应用连接参数三方统一用 utf8mb4，中间不依赖运行时干预。
