navicat运行sql脚本报错主因是编码、版本、执行方式不匹配：需转utf-8无bom，用select version()确认真实库版本，替换utf8mb4_0900_ai_ci等高危语法，必须通过“运行sql文件”而非粘贴执行，并删use/create database语句。
Navicat运行SQL脚本报错不是你写的SQL有硬伤，而是文件编码、目标库版本、执行路径或上下文环境不匹配导致的——比如UTF-8带BOM头被当乱码解析，MySQL 5.7收到utf8mb4_0900_ai_ci直接报ERROR 1273，或粘贴进查询窗口执行大脚本因超时中断且行号错位。
确认SQL文件真实编码并转为UTF-8无BOM
用VS Code打开SQL文件，右下角查看当前编码。若显示为GBK、ANSI或UTF-8 with BOM，必须转换。
点击右下角编码名→选择“Save with Encoding”→选“UTF-8”，不要选“UTF-8 with BOM”。
这一步不可跳过：【BOM头会导致Navicat把第一行识别为非法字符，后续所有CREATE TABLE都报ERROR 1064】
保存后关闭Navicat中已打开的导入窗口，重新进入操作流程。
查清目标库真实版本，而非Navicat连接显示版本
在Navicat中连上目标数据库，新建查询窗口，执行：
SELECT VERSION();
再执行：
SELECT @@version_comment;
如果VERSION()返回5.7.42，但@@version_comment显示“MySQL Community Server (Aliyun)”，说明这是阿里云RDS定制版，不支持ALGORITHM=INSTANT、JSON_OBJECT()默认值等8.0语法。
此时别信Navicat连接属性里写的“8.0.33”——那是握手缓存值，【真实版本以SELECT VERSION()为准】。
替换高危语法：排序规则与时间戳定义
打开已转码的SQL文件，在VS Code中按Ctrl+H全局搜索：
方法一：搜 utf8mb4_0900_ai_ci → 全部替换成 utf8mb4_unicode_ci
方法二：搜 DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP → 删除第二个CURRENT_TIMESTAMP，只留一个
方法三：搜 CREATE OR REPLACE VIEW → 替换为 DROP VIEW IF EXISTS `xxx`; CREATE VIEW `xxx` AS ...（xxx为原视图名）
注意：字段级COLLATE也要改，例如email VARCHAR(100) COLLATE utf8mb4_0900_ai_ci → 改成 COLLATE utf8mb4_unicode_ci
必须用“运行SQL文件”，禁用粘贴执行
右键目标数据库连接 → 选择「运行SQL文件」。
勾选「使用 UTF-8 编码读取文件」。
在「执行前运行自定义命令」框中填入：
SET SESSION sql_mode = '';
这能绕过MySQL 5.7严格模式对零日期、空字符串默认值的拦截。
千万别把整个SQL复制进查询编辑器点执行——【粘贴执行会触发客户端逐条解析，大文件极易因超时、换行符丢失或BOM残留而中断，且错误定位行号完全失真】。
删掉SQL文件开头的USE和CREATE DATABASE语句
用文本编辑器打开SQL文件，删除最前面的这几行（通常在文件顶部10行内）：
DROP DATABASE IF EXISTS `mydb`;
CREATE DATABASE IF NOT EXISTS `mydb` CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
USE `mydb`;
这些语句在Navicat导入向导中会被拒绝执行，报错“权限不足”或“语法错误”。
确保所有表操作都不带库名前缀，例如INSERT INTO users，而不是INSERT INTO mydb.users。
分段执行定位问题语句
第一步：将SQL文件按分号分割，用Notepad++的“扩展模式”查找 ;\r\n 或 ;\n，手动切出前100条语句另存为part1.sql。
第二步：用Navicat「运行SQL文件」执行part1.sql，观察是否报错及具体行号。
第三步：若成功，继续切part2.sql；若失败，把part1.sql拖入VS Code，开启SQL语法高亮，聚焦报错行附近——重点检查中文全角符号、缺失的引号、注释符--后没空格、INSERT中VALUES末尾多逗号等硬伤。
