Navicat可视化界面批量修改表字符集与校对规则教程

许多用户在修改数据库字符集时，常常遇到一个常见误区：在Navicat里将数据库的字符集和校对规则改为`utf8mb4`后，插入emoji表情时依然报错`incorrect string value`。根本原因在于，右键数据库选择「编辑数据库」修改的仅仅是“默认值”，对已存在的表完全不起作用。这个操作只影响后续新建的表，已有表的`default charset`和字段的`character set`并不会自动更新。要真正修改已有表，必须采用其他方法。下面详细讲解三个实用方案，每个方案都有需要注意的关键细节。

Navicat「编辑数据库」只改默认值，不改已有表

右键数据库 →「编辑数据库」→ 修改 character set 和 collation，这个操作仅影响后续新建的表。已有表的 default charset、字段的 character set 全部保持原样。很多用户改完就去插 emoji，立刻报错 incorrect string value，就是因为误以为“库改了，表就跟着动了”。

结构同步（Structure Synchronization）必须手动勾选 Compare collation

这是最常被忽略的开关：Navicat 默认不比对校对规则，即使源表是 utf8mb4_0900_as_cs、目标是 utf8mb4_general_ci，差异列表里也不会标蓝，更不会生成 ALTER TABLE ... CONVERT TO 语句。要让它生效，需按以下步骤操作：

• 进入结构同步向导 → 点击「Options」→ 勾选 Compare collation
• 务必取消勾选 Compare auto-increment value，否则可能意外重置主键起始值
• 源表字段定义中要显式带字符集，比如 name VARCHAR(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci；如果只靠表级默认值，Navicat 可能判定“无差异”
• 比对完成后，在差异列表中筛选类型为 Collation 的条目，逐个确认是否勾选——允许单条取消，避免全量覆盖

直接在查询窗口执行 CONVERT TO 最可控

相比导出 SQL 文件再导入，直接在 Navicat 查询编辑器中粘贴并分批执行 ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci 更安全。文件编码、BOM、混入 CREATE DATABASE 或未设 DELIMITER 都可能让脚本执行失败。推荐的做法是：

• 先运行 ALTER DATABASE your_db_name CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci 设新表默认值
• 用查询生成批量语句：SELECT CONCAT('ALTER TABLE `', table_schema, '`.`', table_name, '` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;') FROM information_schema.tables WHERE table_schema = 'your_db_name';
• 复制结果 → 粘贴进查询窗口 → 关闭自动提交 → 每执行 5 张表就手动 COMMIT 一次
• 表名含横线或数字开头时，` 反引号不能漏，否则语法错误

目标库不支持源 COLLATION 时会静默跳过或报错

比如源用 utf8mb4_0900_as_cs，但目标是 MySQL 5.7 或 MariaDB 10.3，它们不支持该校对规则。Navicat 在结构同步时可能不提示、不标红，直接跳过这条差异；而执行 CONVERT TO 时则会明确报错 Unknown collation。提前排查很关键：

• 提前查目标库支持的校对规则：SHOW COLLATION LIKE 'utf8mb4%';
• 若不支持，得降级为兼容的 utf8mb4_unicode_ci 或 utf8mb4_general_ci
• 达梦 DM8 需确认已启用 UTF-8 模式，否则同样不认 utf8mb4_*

真正生效的关键不在界面点几下，而在于确认每张表的 CONVERT TO 是否实际执行、每条字段的 CHARACTER SET 是否被重写——这些细节在结构同步预览里容易被忽略，必须人工核对。