MySQL插入中文变问号？应用层与服务器层双重排查指南

排查与应用层修复

在深入服务器底层配置之前，先确认应用代码层面的连接配置是否正确。这是最常见且最容易忽略的环节，特别是当数据库本身配置正常时，连接串缺少编码声明会导致数据传输乱码。

第1步：检查数据库连接配置文件

目的：确保Java应用在建立数据库连接时，显式声明了UTF-8字符集。 入口：项目的数据库配置文件（如 Jdbc.properties 或 application.yml）。 动作：查看 spring.datasource.url 或 JDBC 链接字符串中是否包含字符集参数。如果使用的是较老的JDBC驱动或自定义配置，可能缺失该参数。 关键参数：useUnicode=true 和 characterEncoding=UTF-8。 完成状态：URL末尾应类似 ?useSSL=false&useUnicode=true&characterEncoding=UTF-8。

若发现配置项缺失，请立即补全。以Spring Boot常见的数据源配置为例：

spring.datasource.url=jdbc:mysql://localhost:3306/你的数据库名?useUnicode=true&characterEncoding=UTF-8&useSSL=false

第2步：验证Web层编码过滤器

目的：确保HTTP请求进入Controller之前，RequestBody已被正确解码为UTF-8。 入口：项目中的 web.xml 或 Spring Security/Shiro 等安全框架的配置类。 动作：检查是否注册了 CharacterEncodingFilter。这能防止前端传入的中文字符在到达业务逻辑前就被错误解析。 参考代码：

<filter>
	<filter-name>characterEncodingFilter</filter-name>
	<filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class>
	<init-param>
		<param-name>encoding</param-name>
		<param-value>UTF-8</param-value>
	</init-param>
</filter>

部分现代框架默认已包含此类过滤器，但仍建议显式声明以确保环境一致性。

服务端配置与修复

如果应用层配置无误，但中文依然乱码，则问题极大概率出在 MySQL 服务器本身的字符集设定上。默认安装的服务端往往将默认排序规则设为 latin1。

第3步：检查当前字符集变量

目的：诊断服务器当前是否强制使用非 UTF-8 编码。 入口：Linux 终端或 Windows CMD。 动作：登录 MySQL 并执行查询命令查看当前生效的全局及会话级字符集变量。 命令：

mysql -u root -p
show variables like 'char%';

请重点观察 character_set_server 和 character_set_database。如果显示为 latin1，这就是中文变问号的元凶。此时需要修改服务端配置文件。

第4步：修改 MySQL 配置文件

目的：永久修改 MySQL 服务器的默认字符集。 入口：服务器上的 MySQL 配置文件。注意，新版 MySQL (5.7+) 在 Linux 下通常使用 my.cnf 而不是 my.ini。常见路径为 /etc/my.cnf 或 /etc/mysql/my.cnf。 操作提醒：修改系统级文件前，建议先备份原始文件以防误操作导致服务无法启动。

vim /etc/my.cnf

进入编辑模式后，找到 [mysqld] 区块（如果没有则新建）。在该区块下添加或修改以下参数。推荐使用 utf8mb4，它完全兼容 utf8 且支持 Emoji 等特殊字符：

[mysqld]
character-set-server=utf8mb4
collation-server=utf8mb4_unicode_ci

保存并退出编辑器（在vim中输入 :wq）。

第5步：重启 MySQL 服务

目的：使配置文件的更改立即生效。 入口：系统服务管理器（systemd）。 动作：停止并重新启动 MySQL 进程。不同发行版命令可能略有差异，以下为通用 systemd 命令。

systemctl stop mysqld.service
systemctl start mysqld.service

服务重启完成后，再次进入命令行执行 show variables like 'char%'; 进行验证。

此时 character_set_server 应已变为 utf8mb4。新的数据库和数据表在创建时将自动继承此设置。

结果验证与排错建议

完成上述所有步骤后，尝试重新插入一条包含中文的数据进行测试。如果成功存储且读出正常，说明问题已解决。

**排错补充：**
1. **存量数据处理**：上述配置仅对新创建的库表生效。如果已有数据库是 latin1 编码，直接写新数据虽然不会报错了，但旧数据仍然是乱码。转换旧库编码较为复杂，建议导出为 CSV/JSON 文本后再导入。
2. **字段级检查**：极少数情况下，单个字段的 collate（排序规则）被硬编码为非 utf8，可在建表语句中明确指定 DEFAULT CHARSET=utf8mb4。

另外，如果在测试环境中看到某些中间件（如 p6spy 或 Mybatis 插件）的输出日志里中文正常，但实际入库乱码，务必区分“打印日志”和“实际写入”是两个过程。上面的第1步和第2步主要针对应用向数据库发送数据的通道，而第4步针对的是数据库接收后的存储格式。只有两端统一，才能避免问号出现。