根本原因是Navicat按高版本（如8.0+）生成SQL，含utf8mb4_0900_ai_ci、CREATE OR REPLACE VIEW等低版本（如5.7）不支持的语法，导致ERROR 1064或1273；须查实目标库版本、降级兼容模式、手动替换关键词并用“运行SQL文件”执行。
Navicat 导出的 SQL 文件在低版本 MySQL 上执行失败，根本原因不是语法写错了，而是 Navicat 按“它以为的高版本”生成了低版本不认的语法——比如 utf8mb4_0900_ai_ci、CREATE OR REPLACE VIEW、ALGORITHM=INSTANT 这类 8.0+ 特性，5.7 或更早版本直接报 ERROR 1064 或 ERROR 1273。
确认目标库真实版本，别信 Navicat 连接面板上写的
Navicat 连接时读到的版本号可能被代理、RDS 中间件或缓存污染。必须亲自连上目标库执行：
-
SELECT VERSION();—— 看主版本，例如5.7.42或5.6.51 -
SELECT @@version_comment;—— 看有没有云厂商定制标识，例如MySQL Community Server (Aliyun)，这类实例常禁用新特性
如果 VERSION() 返回 5.7.42，但 Navicat 连接属性里显示 8.0.33，那所有导出脚本默认按 8.0 生成，必然在 5.7 上失败。
手动替换 SQL 文件里的高危关键词（目标库 ≤5.7 时必做）
打开导出的 .sql 文件，在 VS Code 或 Notepad++ 中全局搜索并替换以下内容：
-
utf8mb4_0900_ai_ci→ 替换为utf8mb4_unicode_ci（5.7 支持，比utf8_general_ci更准） -
utf8mb4_0900_as_cs→ 同样替换为utf8mb4_unicode_ci -
CREATE OR REPLACE VIEW→ 替换为DROP VIEW IF EXISTS+CREATE VIEW两行 -
DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP→ 删除第二个CURRENT_TIMESTAMP，只留一个 -
utf8mb4→ 全局替换为utf8（仅当目标库是 5.5 或更老时才需要；5.7 可保留utf8mb4，但必须降级 collation）
导出前必须调低 Navicat 的 Compatibility Mode
Navicat 16+ 的「转储 SQL 文件」向导中，这个选项藏在高级设置里：
- 明确选中目标库真实版本，例如
MySQL 5.7（不能留空，不能选“自动”） - 该设置生效后，Navicat 才会真正禁用
CREATE OR REPLACE、移除ALGORITHM和LOCK子句、把utf8mb4_0900_ai_ci自动降级为utf8mb4_general_ci - Navicat 15 及更早版没有该选项，只能手改 SQL 文件或升级客户端
执行时必须用「运行 SQL 文件」而非粘贴执行
复制粘贴进查询编辑器执行，本质是客户端逐条解析 + 发送，大文件容易超时、BOM 头干扰、换行符丢失；而「运行 SQL 文件」走服务端直读，跳过客户端预检：
- 务必勾选「使用 UTF-8 编码读取文件」，且确认是 UTF-8 无 BOM
- 不要在 SQL 文件开头加
SET autocommit = 0;—— Navicat 的「运行 SQL 文件」功能会忽略它 - 如果文件含
CREATE DATABASE或USE，先手动删掉，否则会中断当前连接上下文，让后续语句失效
字符集声明、排序规则、时间戳语法、视图定义方式——这些不是“可选优化项”，而是版本硬边界。漏掉任意一个，都可能卡在第一条 CREATE TABLE 就报错。动手前先查清目标库真实版本，比事后一行行 grep 替换省三倍时间。
