新建表时须在Navicat“选项”页显式选择utf8mb4_0900_ai_ci排序规则，不可依赖MySQL 8.0默认；改已有表必须用ALTER TABLE ... CONVERT TO而非DEFAULT；连接层需设SET NAMES utf8mb4并测试生效。
新建表时直接指定 utf8mb4 字符集
mysql 8.0 默认字符集已是 utf8mb4，但 navicat 新建表时仍可能沿用连接或数据库默认值，不能完全依赖“自动继承”。必须显式确认或设置。
在 Navicat 中右键数据库 → “新建表”，进入设计界面后：
- 点击左下角“选项”标签页
- 找到“排序规则（Collation）”下拉框，手动选为 utf8mb4_0900_ai_ci（MySQL 8.0 官方推荐，默认排序规则）
- 不要只改“字符集（Charset）”而忽略排序规则——两者需匹配，否则字段级操作（如索引、比较）可能异常
- 若该下拉框灰显或不可选，说明当前数据库未设为 utf8mb4，需先执行 ALTER DATABASE db_name CHARACTER SET = utf8mb4 COLLATE = utf8mb4_0900_ai_ci
已有表转 utf8mb4：用 CONVERT TO 而非 ALTER TABLE ... DEFAULT
很多人误用 ALTER TABLE table_name DEFAULT CHARACTER SET utf8mb4，这只会改表默认字符集，**不转换已有字段数据**，字段本身仍保持原 charset，乱码照旧。
正确做法是使用 CONVERT TO，它会真正重写字段定义并尝试转换存量数据：
- 在 Navicat 中右键表 → “查询” → 新建查询
- 执行：
ALTER TABLE your_table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; - 注意：该语句会重建表，锁表时间取决于数据量；生产环境务必在低峰期操作，并提前备份
- 执行后，用
SHOW CREATE TABLE your_table_name检查每个VARCHAR字段是否已带CHARACTER SET utf8mb4，而非仅表头声明
Navicat 连接层必须启用 utf8mb4，否则写入即乱码
即使表和库都设对了，Navicat 连接若没指定 charset，MySQL 会按 character_set_client 解析 SQL —— 默认可能是 latin1 或 utf8（即 utf8mb3），导致中文插入变成问号或 Mojibake。
解决方法：
- 右键连接 → “编辑连接” → “高级”选项卡
- 在“初始命令（Initial command）”中填入：SET NAMES utf8mb4;
- 不要用“字符集（Charset）”下拉框（部分旧版 Navicat 此项无效），SET NAMES 是最可靠方式
- 修改后务必“测试连接”成功再保存，否则配置不生效
字段级字符集不一致时的隐患
MySQL 允许表内不同字段用不同 charset，但这是陷阱。比如一个表整体是 utf8mb4，但某个 TEXT 字段被单独设为 latin1，那么：
- 该字段存中文会失败或截断
- 与其他 utf8mb4 字段做 JOIN 或 CONCAT 时触发隐式转换，性能下降且结果不可控
- Navicat 表结构界面里，字段的“排序规则”列若显示为空或与表不一致，就是线索
排查命令：SELECT COLUMN_NAME, CHARACTER_SET_NAME, COLLATION_NAME FROM information_schema.COLUMNS WHERE TABLE_SCHEMA='your_db' AND TABLE_NAME='your_table';
修复建议：对问题字段单独执行 ALTER TABLE your_table MODIFY column_name VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;
真正麻烦的不是改完就完事——如果历史数据已在 utf8（utf8mb3）连接下写入过表情或生僻字，那些字节已损坏，CONVERT TO 无法还原。这种情况下，只能清空重导，或接受部分字段不可逆乱码。
