本质原因是MySQL服务端版本低于5.5.3，不支持utf8mb4字符集，Navicat发送SET NAMES 'utf8mb4'时服务端无法识别；手动设为UTF-8可绕过报错，因utf8（即utf8mb3）所有MySQL版本均支持，但会导致emoji等四字节字符存储异常。
Navicat报“Unknown character set: 'utf8mb4'”的本质原因
这不是navicat的问题，而是它在尝试协商连接字符集时，向mysql服务端发送了set names 'utf8mb4'（或类似初始化命令），但mysql服务端根本不认识utf8mb4——说明你的mysql版本低于5.5.3。常见于本地装的精简版、老旧集成环境（如xampp旧版、某些docker镜像）、或centos 6默认源里的mysql 5.1。
为什么手动设成UTF8就能绕过报错
因为utf8是MySQL 4.1起就支持的旧字符集别名（实际对应utf8mb3），所有版本都认。Navicat在连接属性里选“UTF-8”后，会改发SET NAMES 'utf8'，服务端顺利执行，连接建立成功。
但这只是“表面通关”，背后有三个隐性代价：
- 所有
CHARACTER SET utf8mb4的建表语句会失败，除非你提前手动替换SQL文件里的utf8mb4为utf8 - 已存的emoji、生僻汉字（如?、?）等四字节字符无法正确存储或读取
- 如果数据库/表实际用了
utf8mb4，而连接用utf8，会出现“存进去是乱码，查出来也是乱码”的双乱码现象
SET NAMES 'utf8'和连接属性设UTF-8的区别
两者效果一致，但触发时机不同：
- 在Navicat连接属性“高级”→“初始命令”里写
SET NAMES 'utf8';：每次连接建立后立刻执行，强制覆盖客户端连接层编码 - 直接在连接属性“编码”下拉框选“UTF-8”：Navicat内部自动注入等效命令，更稳定，推荐优先用这个
- 如果选了“自动”，Navicat会尝试读取MySQL的
character_set_client等变量来匹配，一旦服务端返回utf8mb4而自身不支持，就又掉回报错
真正该检查的三个地方
只改Navicat设置治标不治本。必须同步确认以下三点是否闭环：
- MySQL服务端是否真支持
utf8mb4：SELECT VERSION();看是否 ≥ 5.5.3；再执行SHOW VARIABLES LIKE 'character_set_server';看返回值 - my.cnf里是否漏配关键项：[mysqld]段必须有
character_set_server=utf8mb4，[client]段建议加default-character-set=utf8mb4（MySQL 5.5+仍可用，别信“已废弃”的过时说法） - 数据库和表本身字符集：用
SHOW CREATE DATABASE db_name;和SHOW CREATE TABLE tb_name;确认，不是只看连接设置
很多人的“改完Navicat就乱码”，其实是数据库建的时候用的是latin1，连接设成utf8也救不回来——字符集不一致的坑，永远在存储层，不在连接层。
