必须统一character_set_client、character_set_connection、character_set_results三者为utf8mb4，仅配character-set-server无效；客户端未声明字符集时默认用latin1发送数据，导致中文被错解为问号。
只配 character-set-server=utf8mb4 不管用，客户端连接时仍可能用 latin1 或 utf8 发送数据，导致中文被错解成问号或乱码字节——必须让客户端、连接会话、结果返回三者全部对齐为 utf8mb4。
为什么 mysql 命令行插入中文还是问号？
根本原因不是服务端没设对，而是 mysql 客户端工具自己没声明字符集。它默认读 [client] 和 [mysql] 段配置，而很多人只改了 [mysqld] 段。
-
[client]段的default-character-set=utf8mb4影响所有客户端工具（mysql、mysqldump等） -
[mysql]段的default-character-set=utf8mb4是专为mysql命令行客户端加的“双保险” - Windows 用户注意：
my.ini中路径含空格或反斜杠时，要用正斜杠或双反斜杠，例如basedir=D:/mysql-8.0.46 - 改完必须重启 MySQL 服务，否则配置不加载；
FLUSH PRIVILEGES对字符集无效
连接后 SHOW VARIABLES LIKE 'character\_set%' 三项不全是 utf8mb4 怎么办？
这是乱码第一现场。重点盯住这三项：character_set_client、character_set_connection、character_set_results。只要有一个不是 utf8mb4，写入或查询就可能出问题。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 临时验证：连上后立刻执行
SET NAMES utf8mb4;，再试插入中文。如果好了，说明就是连接层没对齐 -
init_connect='SET NAMES utf8mb4'要加在[mysqld]段里，但它对root或有SUPER权限的用户不生效，这类用户得手动执行或改连接参数 - Navicat、DBeaver 等 GUI 工具需在连接配置里显式勾选“UTF8MB4”或在高级参数中加
characterEncoding=utf8mb4 - Python 的
pymysql连接时要传charset='utf8mb4'；Java JDBC URL 后加&characterEncoding=utf8mb4
mysqldump 导出 SQL 文件后中文变乱码？
导出文件本身已损坏，后续怎么调目标库都没用。问题出在 mysqldump 没带字符集参数，它默认用 latin1 读表，把 utf8mb4 字节当 latin1 解，再写进 SQL 就是错的。
- 正确命令必须把
--default-character-set=utf8mb4放在最前面：mysqldump --default-character-set=utf8mb4 -u root -p mydb > backup.sql - 如果导出给 MySQL 5.7 用，额外加
--compatible=mysql57 --collation-server=utf8mb4_general_ci，避免utf8mb4_0900_ai_ci报错 - 别用
iconv直接转文件编码：从latin1到utf8mb4不是字节映射，是逻辑错位，转完还是乱 - 检查导出文件是否靠谱：
head -n 20 backup.sql | grep CHARSET应该看到DEFAULT CHARSET=utf8mb4；file -i backup.sql应显示charset=utf-8
最容易被忽略的是：即使所有配置都写了 utf8mb4，只要有一处漏掉 [mysql] 段或没重启服务，或者某个应用连接时没显式指定 charset，链路就断在那一环。排查时别猜，先 SHOW VARIABLES 看实时值，再逐层比对。
