必须先执行SELECT VERSION()和SELECT @@version_comment;确认真实版本，再在Navicat中手动设置Compatibility Mode为目标版本，并用“运行SQL文件”方式执行UTF-8编码脚本。
查清连接显示版本和真实版本是否对得上
navicat 左下角或连接属性里写的“mysql 8.0.33”可能只是它握手时收到的缓存值，不是目标库真实版本。真正靠谱的只有两条 sql：select version(); 和 select @@version_comment;。后者能揪出云厂商定制版（比如阿里云 rds 带 (aliyun) 标识），它们常阉割新语法，但 navicat 不会主动提醒。
导出脚本前必须手动设兼容模式
Navicat 16+ 的「结构同步」或「转储 SQL 文件」向导里，Compatibility Mode 默认是空或“自动”，这等于没设——它会按最高支持版本生成语法。必须点开「选项」→「高级」→ 明确选中目标库真实版本（比如 MySQL 5.7）。否则导出会带 ALGORITHM=INSTANT、utf8mb4_0900_ai_ci 这类低版本直接报错的玩意儿。
-
CREATE OR REPLACE VIEW→ 5.7 不认，得拆成DROP VIEW IF EXISTS+CREATE VIEW -
DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP→ 5.7 只允许一个CURRENT_TIMESTAMP，第二个得删掉或替换成字面量 -
JSON_OBJECT()作为默认值 → 8.0.12+ 特性，5.7 执行就崩
别用粘贴执行，改用“运行 SQL 文件”并勾选 UTF-8
把大 SQL 复制进查询窗口执行，本质是客户端逐条解析+发送，容易超时、BOM 头乱码、换行符丢失。而「运行 SQL 文件」走服务端直读，跳过客户端限制。关键操作有三步：
- 文件保存为 UTF-8 编码（无 BOM）
- 在 Navicat「运行 SQL 文件」窗口勾选
UTF-8编码 - 填入「执行前运行自定义命令」：
SET sql_mode = 'NO_ENGINE_SUBSTITUTION';，临时绕过 MySQL 严格模式报错
同步预览页里藏了真实差异，但不告诉你为什么跳过
「数据同步」向导的预览页能列出 INSERT/UPDATE/DELETE 行数，点表名还能看到源 vs 目标字段级差异（黄色高亮）。但它不会说明某行为什么没同步——比如主键冲突被 INSERT IGNORE 跳过，只在最终日志里留一句 Duplicate entry '105' for key 'PRIMARY'。所以同步完必须翻「信息日志」，搜 Duplicate 或 Warning，否则你以为数据全同步了，其实漏了几百行。
字符集不一致（如 utf8mb4 vs utf8）、时间字段时区偏移、甚至表没主键导致全字段比对，都可能让 Navicat 把相同逻辑的数据标成“不同”，但界面不提示原因——这些细节得靠人工交叉验证，没法全自动。
