一眼识别字符集问题：若能查到数据、插入新中文正常、旧数据显为?或æ‘们类mojibake，说明数据未损坏，而是character_set_client/connection/results三者不一致或含latin1/gbk，与utf8mb4字段错位导致解码错误。
怎么一眼看出是字符集问题不是数据损坏
乱码但能查到数据、插入新中文正常、旧数据查出来是?或æ些ææ¬这类Mojibake，基本就是字符集错位——数据本身没丢，只是读的时候用错了编码。真损坏的数据通常表现为字段为空、截断、或报错Incorrect string value。
关键判断点：SHOW VARIABLES LIKE 'character_set_%'里character_set_client、character_set_connection、character_set_results三者不一致，或者其中任一为latin1或gbk，而表字段是utf8mb4，就坐实了字符集链路断裂。
查清四层字符集：服务端、库、表、字段
不能只看SHOW VARIABLES，得逐层确认：
- 服务端默认值：
SHOW VARIABLES LIKE 'character_set_server'和SHOW VARIABLES LIKE 'collation_server' - 当前库：
SHOW CREATE DATABASE your_db_name，看DEFAULT CHARACTER SET和COLLATE - 当前表：
SHOW CREATE TABLE your_table_name，注意表定义里是否显式写了CHARACTER SET utf8mb4 - 具体字段：
SHOW FULL COLUMNS FROM your_table_name，检查Collation列，比如utf8mb4_unicode_ci才对；如果显示latin1_swedish_ci，哪怕库是utf8mb4也没用
连接层才是90%乱码的罪魁祸首
配置文件写对了character-set-server = utf8mb4，但客户端连上来时没声明编码，照样乱。常见坑：
- PHP PDO没设
charset=utf8mb4，只写了host=localhost;dbname=test - JDBC URL漏掉
?useUnicode=true&characterEncoding=utf8mb4，或写成utf8（MySQL的utf8≠标准UTF-8） - 命令行
mysql -u root -p没加--default-character-set=utf8mb4，导致character_set_client默认是latin1 - Navicat/Workbench没在连接属性里勾选“使用UTF8MB4”或手动填
utf8mb4
验证连接层是否生效：连上后立刻执行SET NAMES utf8mb4，再查乱码字段——如果立刻变正常，说明就是连接层没配对。
已有乱码数据还能救吗
不能直接ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4，那只会让乱码更严重。必须先确认原始编码：
- 如果原始存的是
latin1但被当utf8mb4读，可用CONVERT(CAST(CONVERT(col USING latin1) AS BINARY) USING utf8mb4)来回救 - 如果已经是
utf8mb4但显示æ些ææ¬，说明客户端用了latin1解码，修复连接层即可，数据不用动 - 最稳妥方式：导出为
latin1编码的SQL文件，再用utf8mb4重新导入，中间用iconv转码
真正麻烦的是字段里混着不同编码的历史数据——这种得靠业务逻辑+正则+人工核对，没有一键方案。
