MySQL建库时没指定字符集，后续插入中文变问号
默认情况下 MySQL 5.7 及以前版本用
latin1作服务器默认字符集，
SHOW VARIABLES LIKE 'character_set%'能看到
character_set_server是
latin1。哪怕客户端连上时声明了
utf8mb4，只要库、表、列没显式指定，实际存储层仍按
latin1解码——写入中文就变成乱码或问号。
修复不能只改连接参数，必须从存储层入手：
确认当前库字符集：SELECT DEFAULT_CHARACTER_SET_NAME, DEFAULT_COLLATION_NAME FROM INFORMATION_SCHEMA.SCHEMATA WHERE SCHEMA_NAME = 'your_db';如果返回
latin1，先备份数据（
mysqldump --default-character-set=utf8mb4 -c -e your_db > backup.sql） 修改库级字符集：
ALTER DATABASE your_db CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci;但注意：这不会自动更新已有表的字符集，只是设定了新表的默认值
表和字段的字符集不一致导致 SELECT 出来仍是乱码
即使数据库设成
utf8mb4，如果某张表创建时没指定，或字段定义里写了
CHARACTER SET latin1，那数据还是按老规则存的。此时
SHOW CREATE TABLE your_table会暴露问题：字段定义里带
CHARACTER SET latin1或
COLLATE latin1_swedish_ci。
安全转换步骤（避免双编码）：
先查字段当前字符集：SELECT COLUMN_NAME, CHARACTER_SET_NAME, COLLATION_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_SCHEMA = 'your_db' AND TABLE_NAME = 'your_table';对每个需要修复的
VARCHAR/
TEXT字段，执行：
ALTER TABLE your_table MODIFY column_name VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;不要用
CONVERT TO CHARACTER SET——它会尝试重解码，已损坏的数据会被二次破坏 如果字段有索引且长度超 767 字节（如
VARCHAR(255)在
utf8mb4下占 1020 字节），需先删索引再改，否则报错
ERROR 1071 (42000)
数据已经乱码，还能抢救吗？
能抢救的前提是：原始字节没被覆盖，只是被错误解码过一次。比如客户端以
utf8mb4发送“你好”，服务端用
latin1存成两个字节
0xC4 0xE3，之后再用
utf8mb4读出来就是乱码。这种属于“单次错解”，可逆。
典型症状：
SELECT HEX(column_name) FROM your_table返回类似
C4E3BAC3的值（即 GBK 编码的十六进制），而不是
E4BDA0E5A5BD（UTF-8 正确编码）。
修复命令（仅适用于 latin1 存了 UTF-8 字节的情况）：
UPDATE your_table SET column_name = CONVERT(CAST(CONVERT(column_name USING latin1) AS BINARY) USING utf8mb4);
说明：
内层CONVERT(... USING latin1)把当前字段值当
latin1字符串读出来（其实是把 UTF-8 字节当 Latin1 字符解释，得到错误字符串）
CAST(... AS BINARY)强制转为二进制，丢弃字符集语义 外层
CONVERT(... USING utf8mb4)把二进制重新按 UTF-8 解码 务必在测试库验证后再跑生产；若原始数据混有真实
latin1内容，此操作会破坏它
连接层字符集配置不匹配引发隐性故障
即便库、表、字段全设成
utf8mb4，如果客户端连接时没声明字符集，MySQL 仍可能按
character_set_client默认值（常是
latin1）解析请求。现象是：INSERT 正常，但 SELECT 出来的中文显示为问号，或者
WHERE name = '张三'查不到数据。
检查并统一连接字符集：
连接后立刻执行：SET NAMES utf8mb4;（等价于设
character_set_client、
character_set_results、
character_set_connection三个变量） 在 MySQL 配置文件
my.cnf的
[client]和
[mysql]段加：
default-character-set = utf8mb4；在
[mysqld]段加：
collation-server = utf8mb4_unicode_ci和
init-connect='SET NAMES utf8mb4'（对非 SUPER 用户生效） 应用代码中，JDBC 连接串加
useUnicode=true&characterEncoding=utf8mb4；Python 的
pymysql加
charset='utf8mb4'参数
字符集修复不是改几个配置就能一劳永逸的事，核心在于三层一致：客户端声明、连接参数、存储定义。任何一层脱节，都可能让中文在某个环节被截断、替换或误解——而这种问题往往只在特定数据、特定查询路径下暴露，不容易被测试覆盖到。
