90%的error 1064源于navicat按高版本语法生成语句发给低版本mysql，如utf8mb4_0900_ai_ci或algorithm=instant不被5.7支持；须执行select version()和select @@version_comment;确认真实版本，并在navicat中手动设置compatibility mode为对应版本。
90% 的 ERROR 1064 不是你 SQL 写错了，而是 Navicat 按高版本语法生成语句，发给了低版本 MySQL。比如把 utf8mb4_0900_ai_ci 或 ALGORITHM=INSTANT 塞给 MySQL 5.7，服务端直接拒收——它不认，不是你漏了分号。
必须先确认目标库真实版本，别信 Navicat 连接面板上写的
Navicat 连接属性里显示的 “MySQL 8.0.33” 可能是缓存值、代理透传假版本，或 RDS 中间件伪造的。真正起作用的是服务端内核版本：
- 连上目标库，执行
SELECT VERSION();—— 看主版本号（如5.7.42-log） - 再执行
SELECT @@version_comment;—— 看有没有云厂商定制标记（如MySQL Community Server (Aliyun)），这类实例常阉割新语法 - 如果
VERSION()返回5.7.42，但 Navicat 显示8.0.33，那所有导出/同步脚本都默认按 8.0 生成，必然在 5.7 上炸
打开 SQL 文件全局搜索这几个高危关键词
用 VS Code 或 Notepad++ 直接搜，只要目标库 ≤ MySQL 5.7，出现任意一个基本就是报错元凶：
-
utf8mb4_0900_ai_ci或utf8mb4_0900_as_cs→ 替换为utf8mb4_unicode_ci -
CREATE OR REPLACE VIEW→ 改成DROP VIEW IF EXISTS xxx; CREATE VIEW xxx AS -
DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP→ MySQL 5.7 只允许一个CURRENT_TIMESTAMP，删掉第二个 -
ALGORITHM=INSTANT、LOCK=NONE、JSON_OBJECT()默认值 → 全是 8.0.12+ 特性，低版本直拒 -
datetime(0)、timestamp(3)→ 去掉括号，写成datetime、timestamp
Navicat 同步或运行 SQL 文件前，必须手动设 Compatibility Mode
Navicat 16+ 的「结构同步」或「运行 SQL 文件」向导里藏着关键开关，不点开根本不会生效：
- 进入同步设置 → 点「选项」→ 「高级」→ 找到
Compatibility Mode下拉菜单 - 明确选中你查到的真实版本（例如
MySQL 5.7），不能留空，不能选“自动” - 启用后，Navicat 才会真正禁用
CREATE OR REPLACE、移除ALGORITHM子句、把utf8mb4_0900_ai_ci降级为utf8mb4_general_ci - Navicat 15 及更早版没有该选项，只能手改 SQL 或升级客户端
别用“粘贴执行”，必须用“运行 SQL 文件”并勾选 UTF-8
把大 SQL 复制进查询编辑器逐条发送，本质是客户端解析 + 分段提交，容易因 BOM 头、混合换行符（\r\n vs \n）、隐式补全分号导致偏移或截断；而「运行 SQL 文件」走服务端直读，跳过客户端预检：
- 右键目标数据库 → 「运行 SQL 文件」→ 选文件 → 编码选
UTF-8→ 开始 - 不要勾选「忽略错误继续执行」，否则错了一条后面全乱
- 如果文件带 BOM，VS Code 保存时选「UTF-8 without BOM」再重试
最常被忽略的一点：报错位置往往不是真出错行，而是前面缺括号、引号没闭合、注释没结束导致解析器整体偏移——从报错行往上查 3～5 行，重点盯 ( )、' '、" "、` ` 是否成对。
