SET NAMES utf8在source前执行常失效，因其仅影响当前会话字符集变量，而SQL脚本中CREATE TABLE等语句可能覆盖设置或使用不兼容编码（如latin1），导致插入中文乱码或报ERROR 1366。
source 命令前执行 SET NAMES utf8 为什么经常失效
因为 source 是 MySQL 客户端命令，它读取文件内容后逐行发送给服务端执行——但关键点在于：SET NAMES utf8 只影响**当前会话**的 character_set_client、character_set_connection 和 character_set_results，而 SQL 文件里若包含建表语句（如 CREATE TABLE ... DEFAULT CHARSET=latin1），这些语句会直接覆盖连接层设置，导致后续插入中文仍乱码或报 ERROR 1366。
常见错误现象：
- 执行
SET NAMES utf8后source xxx.sql，建表成功但插入中文变成问号 - 脚本里含
DEFAULT CHARSET=utf8mb4，但目标库是utf8（即 utf8mb3），报错Unknown character set: 'utf8mb4' - 脚本头部没
SET NAMES，只靠客户端连接参数，结果部分语句按 latin1 解析
真正起效的 SET NAMES 放置位置和替代方案
SET NAMES 必须出现在 SQL 脚本**最开头**，且在任何 CREATE DATABASE 或 USE 之前；仅在客户端交互中执行一次，对 source 无实际约束力。
实操建议：
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- 用文本编辑器打开 SQL 文件，在第一行插入：
SET NAMES utf8mb4;（注意：优先用utf8mb4，不是utf8） - 如果脚本已含
CREATE DATABASE，确保其后紧跟USE db_name;，再跟SET NAMES utf8mb4;—— 否则数据库切换后连接字符集可能重置 - 避免混合使用：
SET NAMES utf8+DEFAULT CHARSET=utf8mb4，二者不兼容，utf8不支持 emoji，会触发ERROR 1366 - 临时补救：若无法改脚本，可在命令行用
sed -i '1i SET NAMES utf8mb4;' file.sql（Linux/macOS）快速注入
为什么 --default-character-set=utf8mb4 比 SET NAMES 更可靠
mysql 命令行客户端启动时加 --default-character-set=utf8mb4，会强制初始化所有连接相关变量（包括 character_set_client 等），且该设置在解析整个 SQL 流程中全程生效，不受脚本内语句干扰。
对比差异：
mysql -u root -p db_name ：完全依赖脚本内 <code>SET NAMES，失败率高mysql --default-character-set=utf8mb4 -u root -p db_name ：即使脚本无任何字符集声明，也能正确解析 UTF-8 内容-
source方式本质是客户端模拟输入，不走命令行参数通道，所以参数无效；而重定向方式（）由客户端进程统一控制编码流
容易被忽略的底层冲突点
即使 SET NAMES utf8mb4 和导入命令都正确，仍可能乱码——问题往往藏在更底层：
-
character_set_server是latin1：新建数据库默认继承它，导致CREATE DATABASE语句没显式指定CHARACTER SET时，库级编码仍是latin1 - SQL 文件本身不是 UTF-8 编码：用
file script.sql查看真实编码，Windows 记事本保存的 “UTF-8” 实际带 BOM，MySQL 会报语法错误 - 表字段单独设了
CHARACTER SET latin1：即使库和表是utf8mb4，单个VARCHAR列仍可能被定义为latin1，需用SHOW CREATE TABLE逐列确认
最终效果取决于最弱一环：服务端配置、库/表/列定义、连接参数、文件编码，四者缺一不可。漏掉任意一个，SET NAMES 都只是表面功夫。
