在MySQL里往表中插入中文数据却得到乱码，是后台开发和数据分析时极容易碰到的状况。乱码的本质是字符在从客户端到磁盘的流转过程中，编码和解码所使用的字符集不匹配，导致字节被错误解释。要解决这个问题，不能只靠改一处配置，而需要顺着数据写入的路径逐层检查。
一、MySQL字符集处理的基本链路
MySQL处理一条插入语句时，会经历几个关键的字符集转换节点。首先是客户端发送SQL文本，服务端通过character_set_client来理解这条语句的编码；接着，数据会按照character_set_connection进行内部转换；最后，再比照目标表和字段的字符集写入磁盘。如果其中任何一环的编码设置错位，中文就可能变成问号或者莫名其妙的字符。
举例来说，假如你的客户端以UTF-8发送“用户”二字，但character_set_client被设成了latin1，服务端就会按单字节去拆UTF-8的多字节序列，直接造成不可逆的损坏。即便后续环节全是utf8mb4，原始字节已经错了。因此排查乱码，第一步永远是看清这条链路上的各个变量当前是什么值。
1.1 查看当前字符集配置
可以用如下语句快速列出与服务端相关的字符集变量：
SHOW VARIABLES LIKE 'character_set%'; SHOW VARIABLES LIKE 'collation%';
执行后重点看character_set_client、character_set_connection、character_set_database、character_set_results以及character_set_server。如果它们不是统一的utf8mb4，插入中文就存在隐患。很多老版本MySQL默认server是latin1，这就是历史项目乱码的根源。
1.2 查看库、表、字段的字符集
除了服务端变量，每个数据库、每张表、甚至每个字段都能单独指定字符集。用下面的语句检查表结构：
SHOW CREATE TABLE user_info;
输出中会包含类似DEFAULT CHARSET=latin1的信息。如果表或字段是latin1，而你又通过utf8连接写入，MySQL会做隐式转换，中文字节被截断或替换为问号。字段级字符集优先级高于表，表高于库，库高于server，任何一级不统一都可能出问题。
二、常见乱码场景与对应修复方案
实际工作中，乱码通常集中在三种场景：建库建表时没指定字符集、程序连接串漏了编码参数、客户端工具本身编码不对。下面分别说明如何处理。
2.1 建库建表明确指定utf8mb4
最根本的做法是在创建时就统一标准。utf8mb4是MySQL中真正的UTF-8，支持表情符和全部Unicode，而老的utf8只支持三字节。创建语句应写成：
CREATE DATABASE shop DEFAULT CHARACTER SET utf8mb4 DEFAULT COLLATE utf8mb4_general_ci; CREATE TABLE user_info ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) CHARACTER SET utf8mb4 NOT NULL, remark TEXT CHARACTER SET utf8mb4 ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
这样无论连接层如何，表和字段都已锁定为utf8mb4，存储中文不会因表结构而损坏。如果表已经建好且是latin1，可以用ALTER TABLE转换，但需注意原有乱码数据无法自动还原，应优先导出干净数据再重建。
2.2 程序连接层统一编码
以Java的JDBC为例，很多初学者只写jdbc:mysql://127.0.0.1:3306/shop，漏掉编码参数，驱动便使用服务端默认编码。正确写法为：
String url = "jdbc:mysql://127.0.0.1:3306/shop" + "?useUnicode=true&characterEncoding=utf8mb4" + "&connectionCollation=utf8mb4_general_ci";
在PHP的PDO中，也应在初始化时指定：
$pdo = new PDO( 'mysql:host=127.0.0.1;dbname=shop;charset=utf8mb4', 'root', 'password', [PDO::MYSQL_ATTR_INIT_COMMAND => 'SET NAMES utf8mb4'] );
这两种方式都保证了客户端到服务端的字节流被正确理解。如果无法修改连接串，也可以在每次连接后执行SET NAMES utf8mb4;，它等价于同时设置client、connection、results三个变量。
2.3 客户端与导入工具编码
使用命令行mysql客户端时，系统终端编码若为GBK，而MySQL返回utf8mb4结果，屏幕也会显示乱码。此时应在连接前执行set names utf8mb4并确认终端支持UTF-8。用Navicat或DataGrip等图形工具导入SQL文件时，必须检查文件本身保存编码和工具中的“导入编码”选项，二者都要是UTF-8，否则SQL文本在读取阶段就已错误。
对于通过LOAD DATA INFILE导入的场景，也要声明字符集：
LOAD DATA INFILE '/tmp/data.csv' INTO TABLE user_info CHARACTER SET utf8mb4 FIELDS TERMINATED BY ',' LINES TERMINATED BY 'n';
忽略这一句，MySQL会按character_set_database去读文件，中文CSV极易错乱。
三、临时排查与修复的实用命令
当线上出现乱码又不便重启服务时，可以用会话级命令快速验证和止血。以下片段展示了如何在一个连接里统一编码并安全插入：
-- 统一当前会话的字符集
SET NAMES utf8mb4;
-- 确认表的字符集
SHOW CREATE TABLE user_info;
-- 插入中文测试
INSERT INTO user_info (name, remark) VALUES ('张三', '测试中文写入');
-- 查询验证
SELECT name, remark FROM user_info WHERE name = '张三';
若查询出来仍是乱码，说明磁盘上存的已经是错误字节，只能清理后重导。预防胜于治疗，建议在项目初始化脚本中固化字符集配置，并在CI环节用脚本校验SHOW CREATE TABLE输出是否含utf8mb4。
3.1 用表对比理清优先级
下面这张表帮助理解不同层级字符集的作用范围与优先级：
| 层级 | 对应变量或语法 | 优先级 | 说明 |
|---|---|---|---|
| 服务端 | character_set_server | 最低 | 新建库未指定时继承 |
| 数据库 | CREATE DATABASE ... CHARSET | 较低 | 新建表未指定时继承 |
| 表 | CREATE TABLE ... CHARSET | 较高 | 字段未指定时继承 |
| 字段 | 列定义 CHARACTER SET | 最高 | 直接决定数据存储编码 |
从表中可以看出，字段级设置最为直接。因此遇到历史表混杂字符集时，优先用ALTER TABLE修改字段，再处理表与库，最后推动服务端配置调整。
四、总结与最佳实践
解决MySQL插入中文乱码，核心思路是让“客户端发送编码、连接层声明编码、表字段存储编码”三者一致，且都采用utf8mb4。开发阶段就把建库建表语句、连接串参数、客户端工具编码一次性设对，比事后排错成本小得多。
另外建议放弃MySQL旧的utf8别名，直接写utf8mb4，避免四字节汉字或表情存入失败。对于已乱码的数据，不要试图在原表上转码修补，应导出逻辑备份、确认文本编码、重建库表后重新导入。只要链路清晰，中文乱码完全可控。