ERROR 1064 导入报错主因有三：一是表名/字段名与MySQL保留关键字冲突，需加反引号；二是高版本mysqldump导出语法不兼容低版本，应指定--compatible参数；三是存储过程等未正确设置DELIMITER。
MySQL 导入 SQL 文件报错 ERROR 1064：先看是不是保留关键字冲突
绝大多数 error 1064 在导入时出现，根本不是语法写错了，而是你建的表名、字段名撞上了 mysql 的保留关键字（比如 order、group、rank、key）。mysql 5.7+ 默认开启严格模式，碰到关键字不加反引号就直接报错。
实操建议：
- 用
mysql --version确认服务端版本，再查对应版本的官方保留字列表（例如 MySQL 8.0 的完整列表在https://dev.mysql.com/doc/refman/8.0/en/keywords.html） - 把 SQL 文件里所有疑似关键字的标识符（尤其是小写单字字段名）都套上反引号，比如把
order改成`order`，group改成`group` - 别依赖客户端自动转义——Navicat 或 DBeaver 导入时可能“帮你”去掉了反引号，结果执行时崩
mysqldump 导出的文件在低版本 MySQL 导入失败
高版本 mysqldump 默认启用新特性（如 ROW_FORMAT=COMPRESSED、STATS_PERSISTENT=1、JSON 字段定义），老版本 MySQL（如 5.6）根本不认识这些语法，一读就报 ERROR 1064。
实操建议：
- 导出时显式指定兼容目标版本：
mysqldump --compatible=mysql40 --skip-extended-insert（mysql40兼容性最宽，会禁用新语法和部分高级选项） - 避免用
--set-gtid-purged=ON导出，除非目标库也开 GTID；否则导入时会多出无法解析的SET @@GLOBAL.GTID_PURGED语句 - 检查 dump 文件开头是否有
/*!50700 ... */这类条件注释，低版本会忽略，但若里面嵌了非注释内容（比如漏了*/），就会当真语法执行
SQL 文件里混用了存储过程/函数定义，但未重置分隔符
导入含 CREATE PROCEDURE 或 CREATE FUNCTION 的 SQL 时，如果没改 DELIMITER，MySQL 会把过程体里的第一个分号当成语句结束，导致 ERROR 1064 —— 错误位置往往在过程定义中间，非常误导人。
实操建议：
- 确保文件中每个存储对象定义前后都有明确的分隔符切换，例如：
DELIMITER ;; CREATE PROCEDURE my_proc() BEGIN SELECT 1; END;; DELIMITER ;
CREATE PROCEDURE、CREATE FUNCTION、CREATE TRIGGER，逐个确认附近有没有 DELIMITER 配对-e 参数执行整段 SQL；改用 mysql db_name ，它天然支持分隔符解析
字符集声明与实际内容不一致，引发解析中断
SQL 文件开头写了 SET NAMES utf8mb4，但文件本身是 GBK 编码保存的，MySQL 读到非 UTF-8 字节序列时可能卡在某个半截字符上，后续解析错位，表现为莫名其妙的 ERROR 1064，错误位置飘忽不定。
实操建议：
- 用
file -i your_file.sql（Linux/macOS）或 VS Code 右下角编码标识，确认文件真实编码 - 导出时统一用
mysqldump --default-character-set=utf8mb4，并用 UTF-8（无 BOM）格式保存文件 - 导入前手动删掉文件开头的
SET NAMES行，改由客户端连接时指定：mysql --default-character-set=utf8mb4 db_name
真正麻烦的永远不是报错信息本身，而是错误位置和真实原因之间隔着一层编码、一层版本、一层关键字隐式规则。盯着 ERROR 1064 的行号改语法，大概率白忙活。
