ERROR 1064主因是Navicat用高版本语法适配低版MySQL，需先执行SELECT VERSION()和SELECT @@version_comment确认真实版本，再替换utf8mb4_0900_ai_ci等不兼容语法，并在“运行SQL文件”中勾选UTF-8执行。
不是sql写错了，是navicat按高版本语法生成语句，发给了低版本mysql——比如把utf8mb4_0900_ai_ci塞给mysql 5.7，或者带algorithm=instant的alter table丢给5.6，直接触发error 1064。
先确认真实MySQL版本，别信Navicat连接属性里写的
Navicat连接属性显示的“服务器版本”只是握手缓存值，可能被RDS代理、旧配置或中间件污染。必须连上目标库后亲自查：
- 执行
SELECT VERSION();——这才是内核真实版本（如5.7.42-log） - 再执行
SELECT @@version_comment;——看有没有云厂商定制标记（如MySQL Community Server (Aliyun)），它们常阉割新语法
如果VERSION()返回5.7.42，但Navicat连接属性显示8.0.33，说明客户端正用高版本协议连接，却往低版本库里发8.0语法，问题根源就在这。
快速定位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文件”，别复制粘贴执行
把大SQL复制进查询编辑器逐条发送，本质是客户端解析+分段提交，容易因BOM头、混合换行符（\r\n vs \n）、超时中断失败；而「运行SQL文件」走服务端直读，跳过客户端预检，成功率高得多：
- 在Navicat中选择「文件」→「运行SQL文件」
- 勾选「UTF-8编码」（尤其含中文注释或字段值时）
- 确保目标数据库已选中（不能只连上服务器就导入）
真正容易被忽略的是：哪怕你改了所有语法、设对了兼容模式，如果仍用“新建查询+粘贴执行”，Navicat依然会按原始连接参数解析并拆分语句——那些隐藏的USE db_name、自动补分号、换行归一化行为，会让修复前功尽弃。
