为什么phpMyAdmin导出的SQL文件在本地导入时提示字符集冲突？-phpMyAdmin-PHP中文网

根本原因是导出时没对齐源库字符集，而导入时又没强制客户端用对应编码解析；导出前未执行set names utf8mb4或配置未生效，导致sql文件缺失/!40101 set names utf8mb4/声明，且导入时未加--default-character-set=utf8mb4参数。

根本原因是导出时没对齐源库字符集，而导入时又没强制客户端用对应编码解析——不是文件本身“坏了”，是 mysql 连接握手阶段就按错的字符集读取了 sql 里的中文和建表语句。

导出前没设好源库连接字符集，SQL 文件头缺 `SET NAMES utf8mb4`

phpMyAdmin 导出逻辑依赖当前会话的 character_set_client。如果导出前没手动执行 SET NAMES utf8mb4，或数据库配置里 init_connect 没生效，导出的 SQL 就不会带字符集声明，或者只写 SET NAMES utf8（注意不是 utf8mb4）。

打开导出的 SQL 文件，搜前三行：没有 /*!40101 SET NAMES utf8mb4 */ 就说明导出源头没对齐
导出页面的 “格式特定选项” 里勾选 “Add SET NAMES statement” 不够，它只加 SET NAMES utf8，得手动在 phpMyAdmin 的 SQL 窗口先运行 SET NAMES utf8mb4 再点导出
如果源库是 MySQL 5.7+ 且已用 utf8mb4，但导出文件里建表语句还写着 DEFAULT CHARSET=utf8，那一定是导出时连接字符集错了

导入命令漏了 `--default-character-set=utf8mb4`

mysql -u root -p db_name 这种写法默认按 <code>latin1 握手，哪怕 SQL 文件是 UTF-8 无 BOM，里面的 '张三' 也会被截成乱码或问号——SET NAMES utf8mb4 在文件里再靠前也救不回来，因为客户端解析 SQL 字符串时已经错了。

必须显式加参数：mysql --default-character-set=utf8mb4 -u root -p db_name
验证是否生效：导入后立刻执行 SELECT @@character_set_client, @@character_set_connection;，两个都得是 utf8mb4
别信 phpMyAdmin 导入页的 “自动检测字符集”，它常把 UTF-8 BOM 文件识别成 binary，手动选 utf8mb4 才靠谱

SQL 文件带 BOM 头，导致 `SET NAMES` 或建表语句错位

UTF-8 文件开头有 BOM（EF BB BF）时，MySQL 客户端会把它当不可见字符吞掉，结果 SET NAMES 变成 SET NAMES，整行失效；或者建表语句的 CREATE TABLE 被顶到第二行，触发语法错误。

btpanel phpsite 宝塔面板PHP网站

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

下载

Linux/macOS 下检查：hexdump -C your.sql | head -n 1，看开头是不是 ef bb bf
删 BOM：sed -i '1s/^\xEF\xBB\xBF//' your.sql（单引号不能省）
Windows 下用 VS Code 打开 → 右下角点编码名 → “Save with Encoding” → 选 “UTF-8”（明确是“无 BOM”）；别点“另存为 UTF-8”，很多编辑器默认仍带 BOM

目标库版本太低，不认 `utf8mb4` 字符集声明

MySQL 5.5.3 之前压根不支持 utf8mb4，导入时遇到 DEFAULT CHARSET=utf8mb4 或 COLLATE=utf8mb4_unicode_ci 就直接报 #1115 - Unknown character set: 'utf8mb4'，连语法解析都过不去。

先查目标库版本：SELECT VERSION();
若低于 5.5.3，只能二选一：升级 MySQL，或手动替换 SQL 文件里的所有 utf8mb4 为 utf8（注意只是临时 workaround，emoji 和部分生僻字会丢）
别只换 CREATE DATABASE 行，要全局搜 utf8mb4，包括 CREATE TABLE、ALTER TABLE、COLLATE 后面的值