ERROR 1064主因是Navicat用高版本语法适配低版MySQL，需先执行SELECT VERSION()和SELECT @@version_comment;确认真实版本，再替换utf8mb4_0900_ai_ci等不兼容语法，并在“运行SQL文件”中勾选UTF-8执行。
navicat 还原 sql 文件时报 error 1064，90% 不是你 sql 写错了，而是 navicat 用高版本语法去适配低版本 mysql —— 比如把 utf8mb4_0900_ai_ci 发给 mysql 5.7，或者带 algorithm=instant 的 alter table 丢给 5.6，直接炸。
先确认真实 MySQL 版本，别信 Navicat 显示的“服务器版本”
Navicat 连接属性里写的版本只是握手时缓存的，可能被代理、RDS 中间件或旧配置污染。必须亲自查：
- 连上目标库，执行
SELECT VERSION();—— 这才是真实内核版本（比如5.7.42-log） - 再执行
SELECT @@version_comment;—— 看有没有云厂商定制标记（如MySQL Community Server (Aliyun)），它们常阉割新语法 - 如果
VERSION()返回的是5.7.x，但 Navicat 连接属性显示8.0.33，说明客户端“自作聪明”按高版本生成语句，问题根源就在这
快速定位 SQL 文件里的高危语法点
打开你的 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 兼容性模式
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）、超时中断导致中间语句截断，进而触发 near ')' 类错误：
- 务必使用 Navicat 菜单栏的「文件」→「运行 SQL 文件」
- 弹窗中勾选「UTF-8 编码」—— 即使文件本身是 UTF-8，不勾也会乱码解析
- 不要在命令列界面输
source xxx.sql，Navicat 命令列根本不支持该命令，直接报near 'source'
最常被忽略的一点：云数据库（如阿里云 RDS、腾讯云 CDB）返回的 VERSION() 可能和官方版行为不一致，哪怕显示是 5.7.42，也可能不支持某些标准 5.7 语法；遇到反复排查无果的情况，优先查 @@version_comment 输出，它比 VERSION() 更诚实。
