根本原因是MySQL客户端连接时未协商UTF-8编码；需确认SQL文件编码（file -i）、转换为UTF-8（iconv）、清除BOM（sed）、并强制指定客户端编码（--default-character-set=utf8）。
mysql命令行导入SQL时中文变问号
根本原因不是SQL文件本身有问题，而是mysql客户端在连接时没协商出UTF-8编码。即使data.sql是UTF-8无BOM，只要客户端用latin1去解码字节流，就会把“中”（E4 B8 AD）错读成三个西欧字符，最终显示为???。
- 先确认SQL文件真实编码：
file -i data.sql，若输出含charset=iso-8859-1或gbk，必须用iconv -f gbk -t utf-8//ignore data.sql > data_utf8.sql转换 - 清除潜在BOM：
sed -i '1s/^\xef\xbb\xbf//' data.sql - 强制指定客户端编码：不要只写
mysql -u root -p db ，而要加<code>--default-character-set=utf8mb4参数：mysql --default-character-set=utf8mb4 -u root -p db - 检查
~/.my.cnf里[client]段是否设置了default-character-set=utf8mb4，否则该参数每次都要手动加
show variables like 'character_set%' 显示全是 latin1
这说明MySQL服务端和客户端默认都没走UTF-8链路。5.7+版本编译默认仍是latin1，光改表或数据库的字符集没用——连接层一断，数据进来就变形。
-
character_set_server决定新库默认编码，必须在/etc/my.cnf或~/.my.cnf的[mysqld]段设character-set-server=utf8mb4（注意不是utf8） -
collation-server建议同步设为utf8mb4_unicode_ci，避免排序异常 -
character_set_client、character_set_connection、character_set_results这三个变量控制会话级编码，单次连接可用SET NAMES utf8mb4临时修正，但不能替代配置文件持久化设置 - 修改配置后必须重启MySQL服务：
sudo systemctl restart mysql，仅重连客户端无效
ALTER TABLE CONVERT TO CHARACTER SET utf8 仍乱码
用utf8（即utf8mb3）做CONVERT，本质是把已损坏的二进制数据再用错误规则重新解释一遍，反而固化乱码。真正要的是utf8mb4，且需确保源数据字节本身是UTF-8编码。
- 先查表当前编码：
SHOW CREATE TABLE tb_name，确认DEFAULT CHARSET字段值 - 如果原数据已是乱码（比如存了
æ³æ³），CONVERT无法还原，只能从原始正确编码的备份重建 - 正确命令是：
ALTER TABLE tb_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci - 字段级单独改（如只改某列）：
ALTER TABLE tb_name MODIFY COLUMN name VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci
应用连接MySQL时仍乱码
服务端和表都设对了，但PHP/Java/Python应用连上去还是乱码，问题大概率出在连接字符串或驱动配置里没声明charset=utf8mb4。
- PHP PDO示例：
$pdo = new PDO("mysql:host=localhost;dbname=test;charset=utf8mb4", $user, $pass)，缺charset=参数就是隐患 - Java JDBC URL要加
?useUnicode=true&characterEncoding=utf8mb4 - Python PyMySQL连接时传
charset='utf8mb4'参数 - Node.js mysql2模块需在
createConnection里明确charset: 'utf8mb4' - 切记：应用层的
utf8通常指utf8mb4，但MySQL旧版驱动可能不识别，务必查文档确认支持情况
latin1或utf8mb3。从SQL文件编码、客户端参数、服务端配置、表结构定义，到应用连接字符串，五处必须全部对齐utf8mb4，少一处都可能让中文在某个环节被截断或误读。 
