Navicat同步后导出的SQL在目标库报ERROR 1273，主因是源库（如MySQL 8.0）的COLLATE utf8mb4_0900_ai_ci等高版本排序规则不被目标库（如MySQL 5.7）识别；需手动将脚本中所有utf8mb40900* collation替换为utf8mb4_unicode_ci，并删除无效SET语句，或改用「数据传输」功能规避该问题。
navicat 同步后导出的 sql 脚本在目标库运行报错，大概率是 collate 不兼容，不是脚本本身写错了。
为什么同步导出的 SQL 一运行就报 ERROR 1273 (HY000): Unknown collation
Navicat「数据同步」完成后点「保存为 SQL 文件」，生成的脚本默认保留源库（比如 MySQL 8.0）的完整表定义，包括 COLLATE utf8mb4_0900_ai_ci 这类高版本排序规则。但目标库如果是 MySQL 5.7 或更早版本，压根不认识这个 collation，CREATE TABLE 一执行就崩。
这不是 Navicat 导出逻辑有 bug，而是它忠实还原了源结构 —— 它不主动降级适配，也不检查目标库能力。
- 错误信息里只要出现
Unknown collation 'utf8mb4_0900_ai_ci'或utf8mb4_0900_as_cs，基本可直接锁定问题 - 即使目标库字符集也是
utf8mb4，只要 collation 不在它的SHOW COLLATION列表里，就必然失败 - 用
mysqldump --skip-set-charset导出的文件也带这些 collation，和 Navicat 导出是同一类问题
怎么快速改掉不兼容的 COLLATE 声明
别指望 Navicat 自动替换，得手动或脚本处理 SQL 文件。核心动作就一条：把所有 8.0+ 特有 collation 替换成目标库支持的等效项。
- MySQL 5.7 目标库推荐统一替换成
utf8mb4_unicode_ci（比utf8mb4_general_ci更准，且 5.7 默认带） - 搜索并替换全文：
utf8mb4_0900_ai_ci→utf8mb4_unicode_ci，utf8mb4_0900_as_cs→utf8mb4_unicode_ci - 别漏掉字段级 collation，例如
name VARCHAR(100) COLLATE utf8mb4_0900_ai_ci也要改 - 用 VS Code 或 Notepad++ 的「全部替换」功能，开正则模式搜
COLLATE\s+[^\s;]+可批量定位
SET NAMES 在导出 SQL 里完全没用，删了更安全
有人在导出 SQL 开头手动加 SET NAMES utf8mb4; 想“统一编码”，结果毫无作用，还可能干扰解析。
- Navicat「运行 SQL 文件」不模拟真实连接会话，
SET NAMES、SET CHARSET、SET collation_connection全被忽略 - 这类语句只对后续部分查询生效，无法影响 CREATE TABLE 中的
COLLATE解析逻辑 - 实操建议：删掉 SQL 文件开头所有
SET行，尤其SET NAMES和SET @OLD_*类初始化语句 - 真正起效的是 Navicat 连接配置里的「字符集」下拉框——必须设成和目标库
character_set_database一致
比改 SQL 更省事的方案：换用「数据传输」而非「运行 SQL 文件」
如果你只是要把数据从 A 库同步到 B 库，根本不需要导出再运行 SQL —— 「数据传输」功能天然绕过 collation 冲突。
- 它不执行 CREATE TABLE，而是走 INSERT + 字段映射，collation 声明不参与传输流程
- 关键设置：进「高级」页，务必取消勾选
Use same charset，否则 Navicat 会强行把源库字符集写进目标表定义 - 如果目标库默认字符集是
latin1，而你想存中文，先手动执行ALTER DATABASE `dbname` CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci; - 注意：「数据传输」不重建索引/约束/触发器，DDL 变更仍需单独处理
最易被忽略的一点：collation 不匹配往往和 information_schema 中实际登记的值不一致有关。运行前用 SELECT DEFAULT_COLLATION_NAME FROM information_schema.SCHEMATA WHERE SCHEMA_NAME = 'your_db'; 确认目标库默认 collation，别只看连接配置或 SHOW VARIABLES。
