<p>phpMyAdmin 因自研SQL解析器限制无法正确处理/ /多行注释，易致语法错误；应确保注释前后有空白、禁用注释内分号、改用--单行注释，或预处理删除注释后导入。</p>
phpMyAdmin 无法识别 /* */ 多行注释导致 SQL 执行中断
phpmyadmin 默认使用自己的 sql 解析器（非 mysql 原生解析），对 /* */ 注释块的处理较严格：若注释跨行、嵌套，或紧贴语句无空格分隔，就可能在分句阶段直接报错 mysql returned an empty result set (i.e. zero rows) 或更隐蔽的 #1064 - you have an error in your sql syntax，实际错误位置却指向注释之后的第一条有效语句。
这不是 MySQL 的问题，而是 phpMyAdmin 的 PMA_SQP_parse() 解析逻辑限制。它按分号 ; 切分语句，但若注释中含分号（如 /* SELECT * FROM t; */）或注释跨行后紧跟语句（如 /* comment */SELECT 1;），切分会错位。
- 确保所有
/* */注释前后至少有一个空白字符（空格、换行），避免紧贴 SQL 关键字或分号 - 禁止在注释内写分号；如需说明语句，改用
--单行注释（phpMyAdmin 对其兼容性更好） - 若脚本由其他工具生成（如 mysqldump），添加
--skip-comments参数重导出，或手动删掉/*! ... */条件注释块
phpMyAdmin 导入时跳过注释的两种实操方式
与其反复调整注释格式，不如让 phpMyAdmin 主动忽略它们。最可靠的是在导入前预处理 SQL 文件，而非依赖界面设置。
- 用
sed删除所有/* */块（Linux/macOS）：sed ':a;N;$!ba;s|/\*[^*]*\*\+([^/*][^*]*\*\+)*/||g' input.sql > clean.sql
（注意：该正则不处理嵌套，但覆盖绝大多数情况） - Windows 用户可用 PowerShell 一行清除：
(Get-Content input.sql) -replace '/\*[\s\S]*?\*/', '' | Set-Content clean.sql
- 不推荐依赖 phpMyAdmin 的「忽略注释」勾选项（位于导入页面底部），它仅跳过以
--或#开头的单行注释，对/* */完全无效
当必须保留注释时，绕过 phpMyAdmin 的替代执行路径
如果注释含关键上下文（如版本标记 /*!50708 SET sql_mode = 'STRICT_TRANS_TABLES' */），删掉会影响逻辑，此时应脱离 phpMyAdmin 的解析器。
- 通过命令行
mysql直接执行：mysql -u root -p database_name < script.sql
—— MySQL 服务端原生支持所有注释语法 - 若只能用 Web 界面，改用 Adminer（轻量级替代品），它复用 MySQL 的协议层，不自行解析 SQL，
/* */注释零问题 - 在 phpMyAdmin 中拆分脚本：把含注释的大文件，按
;手动切成多个小段，逐段粘贴到「SQL」页执行（适合调试阶段）
容易被忽略的细节：BOM 和 UTF-8 编码干扰注释识别
某些编辑器（尤其是 Windows 上的记事本）保存 UTF-8 文件时会加 BOM（Byte Order Mark），phpMyAdmin 解析时可能将 BOM 视为非法字符，导致第一行注释（哪怕只是 /* */）被截断或错位，进而引发后续所有语句解析失败。
立即学习“PHP免费学习笔记（深入）”；
- 用
file -i script.sql检查是否含 BOM（输出含charset=utf-8-with-bom） - Vim 中执行
:set nobomb | w去除 BOM；VS Code 右下角编码处点击「UTF-8 with BOM」→「Save with Encoding」→ 选「UTF-8」 - 即使注释本身完全合法，BOM 也会让 phpMyAdmin 把
/*识别成/*，从而彻底破坏注释边界判断
phpMyAdmin 的注释问题本质是解析器能力边界，不是配置能彻底解决的。真正省事的做法，是明确区分「开发调试用命令行」和「简单管理用 phpMyAdmin」——后者只处理无注释、单语句、UTF-8 no-BOM 的干净 SQL 片段。
