ERROR 1064真实错误点常在报错行号前3–5行，因MySQL自顶向下解析卡住才报错；需手动跳过空行和注释重数行号，重点检查上一行末尾、本行开头及换行拼接处，并排查版本差异、保留字未加反引号、SQL_MODE被跳过或BOM/截断等问题。
不是导出文件本身有错，而是导入环境和导出时的上下文不匹配——最常见的是 mysql 版本差异、保留字未加反引号、sql_mode 被跳过、或文件含 bom/截断。
报错行号不准，真实错误在提示行号前 3–5 行
MySQL 解析器是自顶向下推导语法树的，只有卡住才报错，所以 ERROR 1064 提示的 at line 12 往往是错误之后的位置。实际问题常藏在上一行末尾或两行拼接处：
- 检查提示行的上一行是否漏了
)或;（尤其INSERT ... VALUES (...)结尾） - 检查本行开头前一个非空格字符：是否多写了分号、引号没闭合、或
IN被换行切成I\nN - 打开 VS Code / Notepad++ 的「显示所有字符」，确认没有隐藏的 UTF-8 BOM（出现在文件最开头，会让
CREATE DATABASE直接失败但报错却指向后面） - 手动跳过空行和
--注释后重数行号，别信 phpMyAdmin 显示的“物理行号”
导出时用高版本 mysqldump，导入到低版本 MySQL 就崩
MySQL 8.0 导出的 JSON 类型、utf8mb4_0900_as_cs 排序规则、WITH 子句、STATS_PERSISTENT=1 等，5.7 及更早版本根本不识别，一读就 ERROR 1064：
- 导出时强制降级：
mysqldump --compatible=mysql40 --skip-extended-insert - 删掉 dump 文件开头的
/*!50700 ... */条件注释（低版本可能漏解析*/，把注释内容当真语法） - 搜索
CREATE TABLE后面有没有ENGINE=InnoDB ROW_FORMAT=COMPRESSED这类 5.6 不支持的选项，手动删掉 - 避免用
--set-gtid-purged=ON，否则会多出SET @@GLOBAL.GTID_PURGED，老版本直接报错
字段名或表名撞上 MySQL 保留关键字
比如字段叫 order、group、rank、key，在严格模式下不加反引号就必然 ERROR 1064，且错误位置飘忽：
- 查对应 MySQL 版本的保留字列表（如 MySQL 8.0 官方列表）
- 用文本编辑器全局搜索小写单字标识符，统一套上反引号：
order→`order`，group→`group` - 别依赖 Navicat 或 DBeaver 自动加引号——它们导出时可能又把反引号去掉了
- 注意 phpMyAdmin 的「SQL」页执行语句时会保留反引号，但「导入」页有时会忽略
SET SQL_MODE 没生效，导致零日期、TYPE=MyISAM 等被拒
导出文件开头的 SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO" 在 phpMyAdmin 「导入」页大概率被跳过，结果后续插入空字符串到数字字段就崩：
立即学习“PHP免费学习笔记（深入）”；
- 手动在 SQL 文件最开头加一行：
SET SQL_MODE = '';或SET SQL_MODE = 'ALLOW_INVALID_DATES'; - 把
TYPE=MyISAM全部替换成ENGINE=MyISAM（5.5+ 已废弃 TYPE） - 把
DEFAULT '0000-00-00 00:00:00'改成CURRENT_TIMESTAMP或删掉 DEFAULT - MySQL 8.0+ 默认禁用
NO_ZERO_DATE和STRICT_TRANS_TABLES，这两个是触发ERROR 1064最频繁的模式项
真正麻烦的从来不是语法本身，而是错误信息不指哪打哪、BOM 隐藏在开头、权限没给到数据库级、或者残留表结构让第二次导入报出完全无关的错误。动手前先清空目标库，再用命令行导入验证真实错误位置，比在 phpMyAdmin 里反复试错快得多。
