MySQL中文乱码根本原因是客户端、连接层、服务端三层字符集不一致；需通过show variables like 'character%'检查并统一为utf8mb4，同时确保表、字段及应用连接字符串均配置正确。
MySQL插入中文乱码，根本原因不是“数据库不支持中文”，而是客户端写入时用的编码、连接传输用的编码、服务端存储用的编码三者不一致。只要这三层对齐，哪怕用 gbk 也能存中文；反之，全设成 utf8 但其中一层漏改，照样乱码。
检查当前字符集配置是否真的统一
别猜，直接查。进 MySQL 后执行：
show variables like 'character%';
重点关注这三项：
-
character_set_client：你输入 SQL 时，MySQL 认为你用的是什么编码（比如 CMD 是gbk，但这里显示utf8，就错位了） -
character_set_connection：连接层转码用的中间编码，必须和client一致，否则会二次转错 -
character_set_database或character_set_server：实际存到磁盘用的编码，得能容纳你传来的字节
常见错误现象：前三项里有任意一个是 latin1 或 gbk，而其他是 utf8，就会在某一层丢字节或乱解。比如 client=gbk，connection=utf8，MySQL 就会把 GBK 的两个字节强行当 UTF-8 解，结果必然是 Incorrect string value 错误。
临时修复：用 set names 快速对齐客户端三件套
适用于开发调试、紧急救火，命令行下立刻生效（但只对当前会话有效）：
set names utf8;
等价于同时执行：
SET character_set_client = utf8;SET character_set_connection = utf8;SET character_set_results = utf8;
注意：set names gbk 也合法——只要你确认终端（如 Windows CMD）确实是 GBK 编码（右键属性 → 代码页是 936），且表本身支持 GBK 字节（比如 latin1 表就不能存 GBK 字节）。但生产环境强烈建议统一用 utf8mb4，避免 emoji 和生僻字问题。
永久生效：修改 my.ini（Windows）或 my.cnf（Linux）
配置文件要分两块改，缺一不可：
- 在
[client]段加：default-character-set=utf8mb4 - 在
[mysql]段加：default-character-set=utf8mb4（这是 mysql 命令行客户端自己的默认） - 在
[mysqld]段加：character-set-server=utf8mb4和collation-server=utf8mb4_unicode_ci
改完必须重启 MySQL 服务（net stop mysql && net start mysql 或 systemctl restart mysqld），否则配置不加载。重启后再次 show variables like 'character%'，确保所有关键项都是 utf8mb4。
别忘了表和字段本身的字符集
即使服务端和客户端全配对了，老表如果建的时候没指定编码，依然可能是 latin1。检查用：
show create table your_table_name;
如果 CREATE TABLE 语句里没带 CHARACTER SET utf8mb4，就得手动转：
- 改库：
ALTER DATABASE your_db_name CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci; - 改表：
ALTER TABLE your_table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; - 如果只想改某个字段：
ALTER TABLE your_table_name MODIFY column_name VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
特别注意：utf8 在 MySQL 里是 utf8mb3 的别名，不支持四字节字符（如 ?、??）。现在新项目一律用 utf8mb4，别省那几个字母。
最容易被忽略的一点：应用代码连接字符串里没显式指定 charset=utf8mb4。比如 Python 的 PyMySQL、Java 的 JDBC URL，都得额外加参数，否则驱动会按老习惯用 latin1 连接——配置文件再完美也没用。
