MySQL建库未指定字符集导致中文变问号，根本原因是服务器默认latin1，需从存储层（库、表、列）逐级改为utf8mb4，并统一客户端连接字符集。
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 正确编码）。
