phpMyAdmin导入SQL后中文注释乱码是解析阶段字符集错位所致，需确保文件为UTF-8无BOM、开头加SET NAMES utf8mb4，并在配置中显式设置charset和connection_charset为utf8mb4。
phpMyAdmin 导入 SQL 后中文注释变乱码，不是文件本身问题，而是 phpMyAdmin 在解析 SQL 时把注释当作了待执行内容，并用错误的字符集解码——它默认按 latin1 或未声明的编码读取文件开头的 UTF-8 字节，导致中文注释（如 -- 创建用户表）被截断或转成问号，但建表语句本身还能执行成功。
确认是不是注释层乱码，而不是数据层
先区分清楚：是 SQL 文件里的中文注释（-- 或 /* */ 中的内容）显示为 ???，还是导入后 SELECT * FROM t 查出来的字段值是乱码？后者是数据存储问题，前者纯属 phpMyAdmin 界面渲染或解析阶段的字符集错位。
- 打开 phpMyAdmin 的“导入”页面，上传前在“Character set of the file”下拉框里选
utf8mb4（不能留空、不能选auto） - 导入完成后，点开对应数据库 → “SQL” 标签页，粘贴原 SQL 文件里带中文注释的一段（比如含
-- 用户登录日志的那几行），手动执行 —— 如果这时注释仍乱码，说明 phpMyAdmin 编辑器没正确解码文件头 - 如果手动执行不乱码，但导入后“结构”页里表注释（
COMMENT）是问号，那是CREATE TABLE语句里没指定COMMENT '中文'的字符集上下文，需补SET NAMES utf8mb4;在文件最开头
SQL 文件必须是 UTF-8 无 BOM，且开头加 SET NAMES
哪怕编辑器显示正常，只要文件带 BOM（EF BB BF），phpMyAdmin 就会在第一行注释前插入不可见字节，导致整段注释偏移解析。而仅靠界面选 utf8mb4 不足以覆盖 BOM 引发的初始解码错误。
- 用命令行确认：
hexdump -C your.sql | head -n 1，看到ef bb bf就必须清除 - Linux/macOS 直接删：
sed -i '1s/^\xEF\xBB\xBF//' your.sql - Windows 下用 VS Code 打开 → 右下角点编码名 → “Save with Encoding” → 选
UTF-8（明确不含 BOM） - 在文件最开头（第一行）插入：
SET NAMES utf8mb4;—— 这条不光影响后续INSERT，也强制 phpMyAdmin 解析注释时对齐编码
phpMyAdmin 配置里 connection_charset 必须显式设为 utf8mb4
即使你每次导入都手动选了 utf8mb4，phpMyAdmin 底层连接初始化仍可能走默认值（尤其旧版本默认用 utf8 别名，实际是 utf8mb3）。注释虽不参与执行，但 phpMyAdmin 的语法高亮和预览逻辑会读取整块文本并按连接字符集做初步 decode。
- 编辑
config.inc.php，找到你的服务器配置段（$cfg['Servers'][$i]） - 加上这两行（缺一不可）：
$cfg['Servers'][$i]['charset'] = 'utf8mb4';和$cfg['Servers'][$i]['connection_charset'] = 'utf8mb4'; - 重启 Web 服务（Apache/Nginx）和 PHP-FPM，否则配置不生效
- 验证是否生效：导入后进 phpMyAdmin，点右上角“新建”，在 SQL 输入框里打
SELECT @@character_set_client;，返回值必须是utf8mb4
真正难处理的是那些已存在、注释被错误解析过的 SQL 文件——它们可能在 phpMyAdmin 的“导入历史”或“最近执行”里留下乱码快照，但实际不影响数据库运行；修复重点永远在源头：确保下次导出时用 mysqldump --default-character-set=utf8mb4，且导出文件保存为 UTF-8 无 BOM，再加 SET NAMES utf8mb4; 开头。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
