utf8mb4是唯一推荐的字符集选项，因其支持4字节Unicode字符，可完整存储中文、emoji、生僻字及数学符号；Navicat建表时须手动选择utf8mb4及对应排序规则，避免误用仅支持3字节的“伪utf8”。
utf8mb4 是唯一推荐的字符集选项
Navicat 新建表时若选 utf8，实际用的是 MySQL 的“伪 UTF-8”（仅支持 3 字节 Unicode），存 emoji 或生僻汉字会直接被截断或报错。必须手动选 utf8mb4，这是目前唯一能完整覆盖中文、emoji、数学符号、古籍用字等全部 Unicode 字符的合法选项。
Navicat 界面里常把 utf8 和 utf8mb4 并列显示，容易误点。注意看排序规则后缀：带 utf8mb4_ 前缀的才是真货，比如 utf8mb4_unicode_ci 或 utf8mb4_general_ci；而 utf8_general_ci 这类属于历史遗留陷阱。
建表时字符集继承链不能靠猜
Navicat 创建表时不显式指定字符集，会按 MySQL 的“字段级 > 表级 > 库级 > 服务器级”顺序继承。但这个链路在 Navicat 里是黑盒——你看到的数据库字符集设置（右键库 → “数据库属性”）只是库级默认值，不代表新建表一定生效。
稳妥做法是：在 Navicat 的“设计表”界面中，点击左下角 Options 按钮，手动将 Character set 下拉框设为 utf8mb4，同时确认 Collation 是 utf8mb4_unicode_ci（比 _general_ci 对中文排序更准）。
如果已经建了表但字符集不对，不要只改表结构，得用 SQL 执行：
ALTER TABLE your_table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
Navicat 连接层字符集必须同步配对
即使表和库都设成 utf8mb4，Navicat 连接本身若用错编码，照样乱码。关键看连接配置里的“高级”页签：
- 勾选
Use compression不影响字符集，但不勾选也不代表安全 - 务必在
Initial statement输入框里填：SET NAMES utf8mb4;—— 这条语句会在每次连接建立时强制客户端、连接、结果三者统一为utf8mb4 - 如果 Navicat 版本较老（如 ≤15.x），
SET NAMES可能被忽略，此时需在 MySQL 服务端配置文件my.cnf中补全：[client]<br>default-character-set = utf8mb4<br>[mysql]<br>default-character-set = utf8mb4<br>[mysqld]<br>character-set-server = utf8mb4<br>collation-server = utf8mb4_unicode_ci
已有表转 utf8mb4 容易漏掉索引长度超限
把旧表从 gbk 或 utf8 转成 utf8mb4 后，VARCHAR(255) 字段实际占用字节数可能从 510 字节（gbk）或 765 字节（utf8）涨到 1020 字节（utf8mb4），超过 InnoDB 单索引 767 字节限制，导致 ALTER TABLE 报错 Specified key was too long。
解决方法不是砍字段长度，而是：
- 先执行
SET GLOBAL innodb_large_prefix = ON;（MySQL 5.7+ 默认已开） - 确保行格式为
DYNAMIC或COMPRESSED：ALTER TABLE your_table_name ROW_FORMAT=DYNAMIC; - 再执行字符集转换命令
这个细节在 Navicat 的图形化操作里完全不可见，必须进查询窗口手动处理。
