1064错误主因是sql文件与目标mysql环境不兼容，需替换aria为innodb引擎、删mariadb专属参数、给保留字字段加反引号、清除utf-8 bom及\r\n换行符，并优先用命令行导入定位真实错误。
wordpress 导入 sql 时在 phpmyadmin 报 #1064，90% 不是语法写错了，而是导出文件和目标 mysql 环境不匹配——比如用了 aria 引擎、含 page_checksum、字段名撞了 order 或 desc 这类保留字，或者导出时用了高版本 mysql 特性但目标库是 5.6/5.7。
检查并替换不兼容的存储引擎和表选项
WordPress 的 wp_commentmeta 或 wp_options 表如果用 Aria 引擎导出（常见于 MariaDB 环境），而你导入到标准 MySQL（非 MariaDB），就会在 PAGE_CHECKSUM=1、TRANSACTIONAL=1 这些地方直接报错。
- 打开 SQL 文件，搜索
ENGINE = Aria，替换成ENGINE = InnoDB（推荐）或ENGINE = MyISAM - 删掉所有
PAGE_CHECKSUM=1、DELAY_KEY_WRITE=1、TRANSACTIONAL=1这类 MariaDB 专属参数 - 如果用的是
ROW_FORMAT=COMPRESSED或STATS_PERSISTENT=1，也一并删掉——MySQL 5.6 不认这些
给保留关键字字段名加反引号
WordPress 插件或自定义表常含 order、group、desc、key 这类字段名，MySQL 8.0+ 严格模式下不加反引号就崩。
- 用文本编辑器全局搜索：
order、group、desc、key、rank、match - 把它们改成
`order`、`group`、`desc`等（注意是反引号，不是单引号） - 别只改
INSERT里的值，重点改CREATE TABLE语句中的列定义和索引定义
确认并清理 UTF-8 BOM 和换行符
phpMyAdmin 对开头的 UTF-8 BOM（EF BB BF）极度敏感，哪怕只是 CREATE DATABASE 前多了一个不可见字符，也会让整段 SQL 解析失败，且错误行号完全乱掉。
- 用 VS Code 打开 SQL 文件 → 右下角点编码（如 “UTF-8 with BOM”）→ 选 “Save with Encoding” → “UTF-8”
- 或命令行检查：
head -n1 dump.sql | hexdump -C，看到开头是ef bb bf就说明有 BOM，需清除 - Windows 导出的文件常用
\r\n换行，某些 phpMyAdmin 版本会把\r当非法字符；用dos2unix dump.sql统一转成\n
跳过 phpMyAdmin 导入，改用命令行定位真错误
phpMyAdmin 报的 at line 12 常滞后 3–5 行，且大文件超时后干脆不报行号。它根本不是调试 SQL 语法的工具，只是个轻量前端。
- 终端执行：
mysql -u root -p your_wordpress_db &1 | head -n 20，错误信息带精确位置和上下文 - 若提示
max_allowed_packet不足，先连上 MySQL 执行：SET GLOBAL max_allowed_packet = 268435456; - 实在要分段试，用
split -l 300 dump.sql part_切片，从part_aa开始逐个导入，快速缩小范围
最常被忽略的一点：phpMyAdmin 的「导入」不是原子操作。一次失败后，可能已建了部分表，下次再导入就会因 Table 'wp_posts' already exists 掩盖原始语法问题。每次重试前，手动执行 DROP DATABASE IF EXISTS `your_db`; CREATE DATABASE `your_db`;——别省这一步。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
