navicat执行sql报错1064主因是连接显示版本与目标库真实版本不一致，需执行select version()和select @@version_comment;确认真实版本，再在同步向导高级设置中手动指定compatibility mode（如mysql 5.7），并使用“运行sql文件”方式执行。
不是你写的 sql 有错，而是 navicat 按“它以为的版本”生成了目标库不认的语法——最常见原因就是 select version() 查出的真实版本和 navicat 连接属性里显示的版本不一致。
查清目标库真实版本，别信 Navicat 连接面板上写的
Navicat 在连接建立时从服务端拿到一个初始版本号，但这个值可能被代理、RDS 中间件或缓存污染。必须亲自连上目标库执行：
-
SELECT VERSION();—— 看主版本，比如5.7.42或8.0.33 -
SELECT @@version_comment;—— 看有没有云厂商定制标识，例如MySQL Community Server (Aliyun)，这类实例常阉割新特性
如果 VERSION() 返回 5.7.42，但 Navicat 连接属性里写的是 8.0.33，那所有同步脚本都默认按 8.0 生成，必然在 5.7 上报 ERROR 1064。
盯住这几个高危语法点，全局搜索就能快速定位
打开 SQL 文件，在 VS Code 或 Notepad++ 里直接搜以下关键词（目标库是 MySQL 5.7 或更低时，出现任意一个基本就是根源）：
-
utf8mb4_0900_ai_ci或utf8mb4_0900_as_cs→ 5.7 不识别，必须替换成utf8mb4_unicode_ci -
CREATE OR REPLACE VIEW→ 5.7 只支持DROP VIEW IF EXISTS+CREATE VIEW -
DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP→ 5.7 仅允许一个CURRENT_TIMESTAMP，第二个得删掉 -
ALGORITHM=INSTANT、LOCK=NONE、JSON_OBJECT()默认值 → 全是 8.0.12+ 特性，低版本直拒
必须手动调低 Navicat 同步向导里的兼容性模式
Navicat 16+ 的「结构同步」或「数据传输」向导中，那个关键开关藏得很深：
- 进同步设置 → 点「选项」→ 「高级」→ 找到
Compatibility Mode下拉菜单 - 明确选中目标库真实版本，比如
MySQL 5.7（不能留空，不能选“自动”） - 这个选项生效后，Navicat 才会真正禁用
CREATE OR REPLACE、移除ALGORITHM子句、把utf8mb4_0900_ai_ci自动降级为utf8mb4_general_ci
Navicat 15 及更早版没有该选项，只能手改 SQL 文件或升级客户端。
别用粘贴执行大脚本，必须用「运行 SQL 文件」并勾选 UTF-8
复制粘贴进查询编辑器执行，本质是客户端逐条解析+发送，大文件容易超时、BOM 头干扰、换行符丢失；而「运行 SQL 文件」走服务端直读，跳过客户端预检，成功率高得多：
- 右键连接 → 「运行 SQL 文件」，不是「新建查询」→ 粘贴
- 导入前务必勾选「使用 UTF-8 编码读取文件」，且确保源文件本身是 UTF-8 无 BOM 格式
- 若脚本含时间字段默认值报
ERROR 1067，可在「执行前运行自定义命令」框填：SET SESSION sql_mode = '';
版本不匹配的问题，从来不是靠猜或试出来的——先查 VERSION()，再锁死兼容模式，最后用对执行方式，三步缺一不可。最容易被忽略的是：改完兼容模式后没点「高级」面板右下角的 OK，等于根本没保存设置。
