根本原因是客户端、连接层、服务端字符集不一致，常见于客户端用utf8mb3而表用utf8mb4且连接未指定utf8mb4；需统一配置并验证各层实际生效。
MySQL客户端连接时中文显示为问号或乱码
根本原因是客户端、连接层、服务端三者字符集不一致，最常见的是客户端声明了 utf8（实际是 mysql 的 utf8mb3），但表用的是 utf8mb4，而连接未显式指定 utf8mb4。mysql 5.7.8+ 默认用 utf8mb4，但很多旧应用仍沿用老配置。
实操建议：
- 检查当前连接字符集：
SHOW VARIABLES LIKE 'character_set%';，重点关注character_set_client、character_set_connection、character_set_results - 连接时强制指定：命令行加
--default-character-set=utf8mb4；JDBC URL 后加?characterEncoding=utf8mb4；Python 的pymysql.connect()显式传charset='utf8mb4' - 避免只改
my.cnf中的collation-server而漏掉init_connect='SET NAMES utf8mb4'，否则普通用户连接仍走默认
ALTER TABLE 修改字符集后数据仍乱码
执行 ALTER TABLE t CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci 看似正确，但如果原数据已以错误编码存入（比如用 latin1 存了 UTF-8 字节），直接转只会让乱码“固化”。这不是编码转换，是重新解释字节流，结果更糟。
实操建议：
- 先确认原始存储状态：用
SELECT HEX(column_name) FROM t LIMIT 1;看十六进制。若中文显示为C3A4C2B8C2A6这类两字节组合，大概率是 UTF-8 字节被当latin1存了 - 修复需分两步：先用
CONVERT(CAST(CONVERT(column_name USING latin1) AS BINARY) USING utf8mb4)类似逻辑做“伪解码”，再更新字段（务必在测试库验证） - 线上操作前备份整表，且禁止在业务高峰执行
CONVERT TO，它会锁表并重写全部数据
Navicat / DBeaver 编辑器里中文正常，但程序读出来是乱码
编辑器和程序走的是不同连接路径：GUI 工具通常自带字符集协商逻辑（如 Navicat 默认发 SET NAMES utf8mb4），而程序依赖驱动配置。问题不在 MySQL 本身，而在客户端代码没对齐。
实操建议：
- PHP PDO 必须在 DSN 中加
;charset=utf8mb4，仅set names不足以保证预处理语句的参数编码 - Node.js 的
mysql2驱动需设charset: 'utf8mb4'选项，不能只靠connection.query('SET NAMES utf8mb4') - Java 的
useUnicode=true&characterEncoding=utf8mb4必须出现在 JDBC URL 末尾，且注意旧版驱动不支持utf8mb4，需升级到 5.1.13+
SHOW CREATE TABLE 显示 utf8mb4，但 EXPLAIN 查看执行计划发现索引失效
utf8mb4 下一个汉字占 3–4 字节，而 VARCHAR(255) 的索引长度上限是 767 字节（InnoDB 默认）。如果字段定义为 VARCHAR(255) 且建了前缀索引或全文索引，实际能索引的字符数可能远少于预期，导致 WHERE 或 ORDER BY 无法走索引。
实操建议：
- 查索引实际长度：
SELECT index_name, SUBSTR(index_columns, 1, 30) AS cols, seq_in_index, length FROM information_schema.statistics WHERE table_name = 't' ORDER BY index_name, seq_in_index; - 若字段长度超限，要么缩短
VARCHAR定义（如VARCHAR(191)在utf8mb4下刚好 764 字节），要么启用innodb_large_prefix=ON并调大innodb_file_format=Barracuda（MySQL 5.7+ 默认开启） - 别忽略排序字段：
ORDER BY title若title是utf8mb4且无索引，即使查询快，排序也会触发Using filesort
字符集问题从来不是单点配置，而是客户端、传输链路、服务端、存储格式四层叠加的结果。最容易被跳过的环节，是应用启动时驱动是否真正生效——光看 SHOW VARIABLES 正确没用，得抓包看 TCP 流里 Handshake Response 包含的 charset 值。
