MySQL中文乱码根本原因是客户端、连接层、表字段三者字符集不一致；必须统一为utf8mb4，且需在连接参数、建表语句、驱动配置等各层显式指定，缺一不可。
MySQL 查询结果中文显示为问号或乱码
根本原因几乎都是客户端、连接层、表字段三者字符集不一致，不是单改某一处就能解决的。最常踩的坑是只改了数据库默认字符集，却忘了应用连接时没指定 charset=utf8mb4。
- 查当前连接实际使用的字符集：
SHOW VARIABLES LIKE 'character_set%';，重点关注character_set_client、character_set_connection、character_set_results是否全为utf8mb4 - 建表时必须显式指定字段字符集：
CREATE TABLE t (name VARCHAR(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci);，仅靠数据库默认值不可靠 - PHP 使用 PDO 时，DSN 必须带参数：
mysql:host=localhost;charset=utf8mb4；用 mysqli 则需在connect()后立刻调用set_charset('utf8mb4') - Python 的
pymysql或mysql-connector-python同样要在连接参数中传charset='utf8mb4'，漏掉就退化成latin1
Java 应用里 PreparedStatement 插入中文变乱码
现象是插入成功但查出来是问号，或者日志里打印 SQL 是正常的，进库就变形——这基本锁定在 JDBC 连接 URL 缺少编码声明或驱动版本太老。
- JDBC URL 必须包含两个关键参数：
useUnicode=true&characterEncoding=utf8mb4（注意是utf8mb4，不是utf8） - MySQL 5.7+ 推荐使用
mysql-connector-java 8.0+驱动，旧版对utf8mb4支持不完整，即使 URL 写对了也无效 - Spring Boot 中配置
spring.datasource.url时，& 符号要写成&，否则 XML/properties 解析会截断 - 别信“服务器已设好全局字符集”这种说法，JDBC 连接初始化时会覆盖服务端设置，必须在 URL 层面强制指定
Navicat / DBeaver 等客户端显示乱码
不是数据库问题，是客户端自身编码设置和连接配置没对齐。这类工具通常有两层控制：软件界面编码 + 数据库连接编码，缺一不可。
- Navicat：右键连接 →「编辑连接」→「高级」页签 → 勾选「使用 MySQL 字符集」并确保下拉选的是
utf8mb4 - DBeaver：连接属性 →「Driver properties」→ 找到
characterEncoding，值设为utf8mb4；同时主菜单「Window → Preferences → General → Workspace」里文本文件编码也要设为UTF-8 - 命令行
mysql客户端启动时加参数：mysql --default-character-set=utf8mb4 -u root -p，否则默认用latin1 - 如果改完仍乱码，检查终端本身是否支持 UTF-8（Linux/macOS 一般没问题，Windows CMD 默认是 GBK，建议换用 Windows Terminal 或 Git Bash）
ALTER TABLE 修改字符集后查询还是乱码
执行了 ALTER TABLE t CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci 却没用？说明只是改了表结构定义，原数据字节流没重编码，相当于“换了个标签贴在错的数据上”。
- 先确认原始数据是否已损坏：用十六进制查看字段内容，比如
SELECT HEX(name) FROM t LIMIT 1;，若返回类似C3A4C2B8C2A1这种，大概率是“UTF-8 字节被当 GBK 解释过两次”，无法无损恢复 - 真正安全的做法是：导出时用
mysqldump --default-character-set=latin1（把现有乱码当原始字节导出），再用iconv转码，最后导入时指定--default-character-set=utf8mb4 - 线上表慎用
CONVERT TO，它会锁表且对大表极慢；优先考虑新建表 + INSERT SELECT + 重命名切换 - 修改列字符集要用
MODIFY COLUMN或CHANGE COLUMN，只改表默认字符集不影响已有列
SHOW VARIABLES 和 HEX() 开始，比猜快得多。 
