错误来源分两类：一是MySQL服务端不支持utf8mb4（如≤5.5.2、精简版MariaDB、旧Docker镜像），需检查SHOW CHARACTER SET LIKE 'utf8mb4'是否返回；二是Navicat客户端过旧（如≤11.2），其SQL解析器预检即拒绝utf8mb4关键字，与服务端版本无关。
确认错误来源是服务端还是Navicat客户端
报错 unknown character set: 'utf8mb4' 看似是连接问题，实则分两类：一类是 mysql 服务端压根不支持 utf8mb4（常见于 mysql ≤5.5.2、精简版 mariadb、或 docker 中的 mysql:5.1 镜像）；另一类是 navicat 客户端版本太旧（如 navicat 11.x 及更早），其内置字符集映射表没注册 utf8mb4，在解析 sql 文件时就直接拒绝，根本没发到服务端。
先执行：SELECT VERSION(); 和 SHOW CHARACTER SET LIKE 'utf8mb4';。若后者无返回，说明服务端不支持；若返回正常但 Navicat 导入仍报错，则大概率是客户端限制。
服务端不支持 utf8mb4 的修复步骤
这不是改 Navicat 设置能绕过的——SET NAMES utf8mb4 连接命令在报错前根本没机会执行，错误发生在服务端 SQL 解析器读到 DEFAULT CHARSET=utf8mb4 的建表语句时。
- 检查
character_sets_dir路径：SHOW VARIABLES LIKE 'character_sets_dir';，进该目录看是否存在utf8mb4.xml - 若缺失，可复制一份
utf8.xml改名为utf8mb4.xml，并修改其中<charset name="utf8mb4">及所有id值（不能与已有重复） - 编辑
Index.xml，末尾新增一行：<collation name="utf8mb4_general_ci" id="45" charset="utf8mb4"/>（id必须全局唯一，查现有最大值后+1） - 在
my.cnf的[mysqld]段添加：character-set-server = utf8mb4和collation-server = utf8mb4_unicode_ci - 重启 MySQL：
systemctl restart mysql或service mysqld restart，再验证SHOW CHARACTER SET LIKE 'utf8mb4';
Navicat 客户端版本过旧导致的兼容问题
即使 MySQL 是 8.0 且已正确配置，Navicat ≤11.2 仍会报 Unknown character set: 'utf8mb4'，因为它基于旧版 MySQL C API，语法预检阶段就硬校验字符集关键字。
此时降级不是妥协，而是必要操作：
- 导出 SQL 文件时加参数：
mysqldump --default-character-set=utf8，让 dump 输出用utf8（即 utf8mb3）替代utf8mb4 - 手动替换 SQL 文件中的
utf8mb4为utf8，注意同步替换utf8mb4_*排序规则（如utf8mb4_unicode_ci→utf8_unicode_ci） - Navicat 连接属性中，“编码”下拉框选
UTF-8（不是“自动”），它会发SET NAMES 'utf8'，服务端全版本都认 - 升级 Navicat 到 12+ 或最新版，彻底避开客户端映射表缺失问题
别踩这些坑
很多尝试失败，是因为混淆了层级：
-
SET NAMES utf8mb4写在 Navicat “初始化命令”里完全无效——错误发生在连接建立前的 SQL 解析阶段 - 只改
my.cnf里的character-set-server不够，必须确保character_sets_dir下有完整utf8mb4描述文件，否则重启后SHOW CHARACTER SET仍不显示 - 数据库/表本身用的是
latin1，光把 Navicat 编码设成UTF-8，只会让乱码更稳定 -
gb2312报错同理：目标 MySQL 没加载该字符集，就得提前把 SQL 文件里的gb2312全局替换成utf8，并确认网页层、应用层也同步改
真正要盯住的只有三处：MySQL 版本是否 ≥5.5.3、character_sets_dir 是否完整、Navicat 是否旧到不认识 utf8mb4 关键字——其余都是障眼法。
