如何解决WordPress在phpMyAdmin中导入SQL时的语法错误？-phpMyAdmin-PHP中文网

90%的wordpress sql导入#1064错误实为假性报错，主因是phpmyadmin解析机制滞后（行号需向上回溯3–5行查括号/引号/bom）、版本兼容问题或utf8mb4校对规则不匹配；大文件应优先用mysql命令行导入以获精准错误定位。

直接结论：90% 的 wordpress sql 导入语法错误，不是你写错了 sql，而是 phpmyadmin 解析机制、mysql 版本升级后的严格模式、或字符集校对规则不匹配导致的假性报错。

phpMyAdmin 报的 #1064 - You have an error in your SQL syntax 后面带的行号（如 at line 12），往往指向错误发生之后的某行——因为 MySQL 解析器是在语法无法继续推导时才报错，不是逐行扫描。

把报错 SQL 复制出来，粘贴到 VS Code 或 Notepad++，打开「显示行号」
从报错提示的行号开始，向上回溯 3–5 行，重点检查：INSERT 末尾是否缺 ) 或 ;、VALUES 里引号是否成对、\' 转义是否漏了
如果 SQL 含中文或特殊字符，用编辑器「编码检测」确认是不是 UTF-8 BOM 搞鬼——BOM 会卡在开头，让 CREATE DATABASE 直接失败
别信 phpMyAdmin 界面里那条波浪线（~），它常因注释、换行、粘贴格式偏移，只盯末尾的 line X

这不是语法问题，是上传链路被拦住了。phpMyAdmin 导入走的是 PHP 文件上传流程，涉及 Web 服务器、PHP、MySQL 三层限制，任一环节卡住都会静默失败或报这个笼统错误。

优先改用命令行导入：mysql -u root -p wordpress_db ，绕过所有前端限制，错误信息带精确行号和上下文
若必须用 phpMyAdmin，先切分文件：split -l 500 dump.sql part_（每 500 行一个片段），逐个导入定位
检查三处关键配置是否对齐：upload_max_filesize、post_max_size（需 ≥ 前者）、max_execution_time；Nginx 还要加 client_max_body_size，Apache 加 LimitRequestBody
注意：phpMyAdmin 的 config.inc.php 中若硬编码了 $cfg['UploadDir']，但目录权限不对，也会静默失败

这是 WordPress 导出文件默认用 utf8mb4 字符集，但你的数据库或表还是老的 utf8（即 utf8mb3），校对规则不匹配导致的硬性拒绝。

Seo Keyword Researcher

为任意主题进行SEO关键词调研，并生成完整文章摘要，包括主关键词、次关键词、竞争分析、文章结构等。

下载

最稳妥解法：进 phpMyAdmin，选中目标数据库 → 「操作」→ 将「数据库字符集」设为 utf8mb4，「校对规则」选 utf8mb4_unicode_ci → 执行
临时绕过（不推荐）：用文本编辑器打开 SQL 文件，全局替换所有 utf8mb4_unicode_ci 为 utf8_unicode_ci，但可能丢失表情符号支持
若 MySQL 版本 utf8mb4 不可用，必须升级 MySQL，不能硬改
别只改数据库层——表和字段的字符集也要同步，否则导入后中文仍乱码

很多 WordPress 导出的 SQL 开头有 SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO"，但 phpMyAdmin 导入时可能跳过这行（尤其用「导入」页而非「SQL」页），结果后续 INSERT 遇到空字符串插数字字段就崩。

手动在 SQL 文件最开头加一行：SET SQL_MODE = '';（清空模式）或 SET SQL_MODE = 'ALLOW_INVALID_DATES';（按需放宽）
不要依赖导出时的 SQL_MODE 注释，phpMyAdmin 不保证执行所有 SET 语句
WordPress 导入后网站打不开？大概率是 wp_options 表里 siteurl 和 home 还指向原站地址，不是语法错误，导入后立刻改这两行值
修复后重试仍报同样错误？可能是残留结构干扰——每次修复前先清空库：DROP DATABASE IF EXISTS `wordpress`; CREATE DATABASE `wordpress`;