如何修复phpMyAdmin导入SQL时由于注释语法导致的报错？-phpMyAdmin-PHP中文网

删掉sql文件开头的注释块可解决多数#1064报错，因phpmyadmin解析器对mysql条件注释、多行注释及set语句兼容性差，易误解析导致语法错误假象。

直接删掉 sql 文件开头的注释块，尤其是含 mysql 版本声明、phpmyadmin 导出头或 set 语句的多行注释，能解决绝大多数因注释引发的 #1064 报错。

为什么注释会触发 SQL 语法错误

phpMyAdmin 的 SQL 解析器对注释的容忍度远低于 MySQL 命令行客户端。它不完全支持 MySQL 8.0+ 引入的某些注释语法（如 /*!80023 CREATE TABLE ... */），也不处理跨多行的 /* ... */ 注释中嵌套的分号或未闭合结构。更常见的是：导出文件头部的注释块里混着 SET 语句（如 SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO"），而 phpMyAdmin 在「导入」页默认跳过所有 SET 行——结果后续 INSERT 因严格模式被拒，却报成“near 'INSERT' at line X”的假性语法错误。

列表中的典型问题：

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */ 这类条件注释在低版本 MySQL 或 phpMyAdmin 中会被当作文本解析，导致 /*! 后面的内容被误读为关键字
注释末尾漏了 */，整个后续 SQL 被吞进注释范围，直到文件结束才爆错
注释里出现 Windows 换行符 \r\n，某些 phpMyAdmin 版本会把 \r 当非法字符，报错位置飘忽

哪些注释必须手动清理

打开 SQL 文件，在纯文本编辑器（如 VS Code、Notepad++）中按行号定位，优先删除以下内容：

文件最开头连续 5–10 行的 -- phpMyAdmin SQL Dump 及其下方所有 -- 开头的元信息（版本、时间、主机等）
所有以 /*! 开头、*/ 结尾的条件注释块，哪怕它看起来只是个版本提示
单独成行的 SET 语句（如 SET SQL_MODE = ...、SET NAMES utf8mb4），它们在导入页不执行，反而干扰解析
结尾处孤立的 ; 或空行前的 -- 注释，可能造成最后一行 SQL 少分号

保留注释的底线操作

如果你必须保留部分说明性注释（比如表用途备注），只允许用单行 -- 形式，且必须满足：

btpanel phpsite 宝塔面板PHP网站

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

每行仅一个 --，后面紧跟空格和文字，不能紧贴 SQL 关键字（如 --SELECT * FROM users; 是错的）
不能出现在 VALUES ( 括号内、引号字符串中间、或字段名/表名的反引号之间
避免在 INSERT 语句末尾加 -- comment，容易被解析器截断导致缺 ) 或 ;

示例安全写法：-- 用户表初始化数据 单独一行；危险写法：INSERT INTO `users` VALUES (1, 'admin'); -- 管理员账号（分号后注释易丢）

验证注释是否干净的最快方式

删完注释后，别急着导入。先做两件事：

用 head -n 20 dump.sql（Linux/macOS）或记事本打开前 20 行，确认首行是 CREATE DATABASE、USE `db_name`; 或 CREATE TABLE，不是 -- 或 /*!
把文件拖进 VS Code，打开「编码」状态栏，确保是 UTF-8（无 BOM）；再按 Ctrl+Shift+P → 输入 “Toggle Render Whitespace”，检查是否有隐藏的 \r 或异常空格
若仍报错，复制报错提示里的 near 'xxx' at line N，回到编辑器手动数第 N 行——重点看该行开头有没有残留的 -- 或 /*，以及上一行结尾是否漏了 ;