mysql迁移后中文显示问号或乱码，根本原因是客户端与服务端字符集不一致，需逐层验证client/connection/results/table/column五层编码是否统一为utf8mb4。
MySQL迁移后SELECT中文显示问号或乱码
这是典型的客户端连接字符集与服务端不一致导致的。迁移时只导出了数据但没同步 character_set_client、character_set_connection、character_set_results 这三个会话级变量的默认值，结果客户端用 latin1 去解码服务端返回的 utf8mb4 字节流，自然变成一堆 ? 或 。
实操建议：
- 先确认当前连接实际生效的字符集：
SHOW VARIABLES LIKE 'character\_set%';，重点关注三连项（client/connection/results）是否统一为utf8mb4 - 临时修复：执行
SET NAMES utf8mb4;（等价于同时设 client/connection/results），立刻生效，但仅对当前会话有效 - 永久修复：在客户端配置文件（如 MySQL Workbench 的 Connection → Advanced → Others 添加
characterSet=utf8mb4；或命令行加--default-character-set=utf8mb4） - 如果用 JDBC，URL 必须显式带上参数：
?useUnicode=true&characterEncoding=utf8mb4，缺一不可
mysqldump 导出的 SQL 文件本身含乱码
说明 dump 时没指定源库字符集，mysqldump 默认按 latin1 读表结构和数据，遇到 utf8mb4 表就直接错位转义，生成的 SQL 里中文已损坏，再怎么改目标库设置都救不回来。
实操建议：
- 重导出必须加
--default-character-set=utf8mb4参数，且该参数要放在mysqldump命令最前面（位置敏感） - 验证导出文件编码：用
file -i your.sql看是否为charset=utf-8；用head -n 20 your.sql | grep CHARSET检查 CREATE TABLE 语句末尾是否有DEFAULT CHARSET=utf8mb4 - 如果已用错编码导出，不能靠
iconv盲目转换——因为latin1到utf8mb4不是简单字节映射，而是逻辑错位，需从原库重新 dump
目标库表结构声明了 utf8mb4，但字段存进去还是乱码
表级字符集只是默认值，真正决定存储编码的是字段自身的 CHARACTER SET 属性。迁移脚本若用 CREATE TABLE ... DEFAULT CHARSET=utf8mb4，但字段定义里写了 VARCHAR(255) CHARACTER SET latin1，那这个字段仍按 latin1 存储，后续任何连接设置都无效。
实操建议：
- 检查具体字段编码：
SHOW FULL COLUMNS FROM table_name;，看Collation列是否为utf8mb4_0900_ai_ci类型（不是latin1_swedish_ci） - 批量修正字段编码：
ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;（注意：此操作会锁表，大数据量慎用） - 若只想改某字段：
ALTER TABLE table_name MODIFY column_name VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; - 迁移前务必确认源库字段真实编码，别只信建表语句里的 DEFAULT
应用层插入正常但 SELECT 出来是乱码
说明写入时连接用了正确字符集（如 SET NAMES utf8mb4），但读取时连接被重置或复用旧连接池配置，导致读连接用的是 latin1。常见于长连接池未刷新会话变量，或中间件（如 ProxySQL）转发时丢弃了字符集上下文。
实操建议：
- 在应用代码里每次获取连接后强制执行
SET NAMES utf8mb4（部分 ORM 如 Django 的OPTIONS['init_command']可配） - 检查连接池配置：HikariCP 的
connection-init-sql、Druid 的connectionInitSqls都支持设初始化 SQL - 用
SHOW PROCESSLIST查看活跃连接的Command和State，结合SELECT @@character_set_client, @@character_set_results;确认每个连接的实际状态 - ProxySQL 等代理层需检查
mysql_query_rules是否有规则覆盖了字符集设置
最易被忽略的是：同一个 MySQL 实例里不同数据库、不同表、甚至同一张表的不同字段，字符集可能完全不一致。不要假设“设了全局变量就万事大吉”，得逐层验证 client→connection→results→table→column 五层编码是否真正对齐。
