答案是：执行show variables like 'character_set_%';可查连接层三变量，character_set_client、character_set_connection、character_set_results必须一致为utf8mb4，否则中文显示为问号或乱码；不一致时mysql会自动转码但易丢字符。
查连接层三变量：character_set_client/connection/results
乱码不是“存错了”，而是客户端发过来的字节被 MySQL 用错的编码去解——character_set_client、character_set_connection、character_set_results 这三个值必须一致且为 utf8mb4，否则 SELECT 出来的中文就是问号或 Mojibake。
执行这条命令直接定位问题：SHOW VARIABLES LIKE 'character_set_%';
- 如果其中任意一个是
latin1或gbk，说明连接时没声明编码，哪怕表是utf8mb4也白搭 -
character_set_database和character_set_server不影响传输，只管新建库/表的默认继承，别被它误导 - 临时补救可用
SET NAMES utf8mb4;，但仅对当前会话生效，不能替代连接参数
查表和字段实际编码：别信“默认”
新建库时设了 DEFAULT CHARSET=utf8mb4，不代表里面所有表、所有字段都用了它。MySQL 表级和列级编码可以单独覆盖，而且很多 ORM 或 SQL 导入脚本根本不会显式写 CHARACTER SET。
查表真实编码：SHOW CREATE TABLE your_table_name\G;
查字段级编码（尤其 varchar/text 类型）：SHOW FULL COLUMNS FROM your_table_name;
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
- 看到
DEFAULT CHARSET=latin1或字段类型后没带CHARACTER SET utf8mb4，就是隐患点 -
ALTER TABLE t CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;会重建整张表，大表慎用；若只想改某字段，得用MODIFY COLUMN xxx VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; - 只改
DEFAULT CHARSET不等于改了已有数据的编码，真正生效要靠CONVERT TO或重新导入
查配置文件是否兜底生效
my.cnf 里写了 character-set-server=utf8mb4，不代表它真起作用——客户端连接时主动声明的字符集优先级更高，配置文件只是兜底。
检查配置是否加载：SHOW VARIABLES LIKE 'character_set_server'; 输出值必须是 utf8mb4，否则配置没生效或被其他段落覆盖
-
[mysqld]段必须有character-set-server=utf8mb4和collation-server=utf8mb4_unicode_ci -
[client]段加default-character-set=utf8mb4，能让命令行工具（如mysql -u root -p）默认用对编码 - 改完配置必须重启 MySQL 服务，
service mysql restart或systemctl restart mysqld - 注意：MySQL 8.0+ 默认已是
utf8mb4，但老版本（如 5.7）默认仍是latin1，别假设版本一致
验证 Emoji 和韩文是否真能存
光看中文不乱，不代表编码真对。微信昵称、用户评论、韩文名这些 4 字节 UTF-8 字符（U+1F600 以上 emoji、U+AC00–U+D7AF 韩文字母）才是终极压力测试。
手动插入测试：INSERT INTO test_table (name) VALUES ('?? 한글 테스트');
- 如果报错
Incorrect string value，说明表/字段没用utf8mb4，或者连接层三变量没对齐 - 如果存进去了但 SELECT 显示为 或空格，大概率是
character_set_results不是utf8mb4，客户端在解码阶段翻车 - Navicat / DBeaver 等 GUI 工具需单独设置“连接属性 → 字符集”为
utf8mb4，不能只依赖 MySQL 配置
最易忽略的是客户端环境本身：Windows cmd 默认代码页是 936（GBK），即使 MySQL 全配对，终端也解不出 UTF-8 字节——这时得用 chcp 65001 切换，或换用支持 UTF-8 的终端（如 Windows Terminal、iTerm2）。
