Navicat自动化执行SQL脚本中文乱码的核心原因是文件编码、Navicat读取编码、连接层声明编码三者不一致；必须手动在“运行SQL文件”中选UTF-8（无BOM）、脚本首行加SET NAMES utf8mb4、表结构显式设utf8mb4，并禁用SQL预处理。
navicat 自动化执行 sql 脚本时中文乱码，核心问题不是脚本内容错了，而是 navicat 读取文件时用的编码 ≠ 文件真实编码 ≠ 连接层声明的编码 —— 三者只要错一个，中文就变问号或方块。
运行SQL文件前必须手动指定文件编码
Navicat 的「运行 SQL 文件」功能不会自动识别 .sql 文件的真实编码。它默认按当前「编辑器默认字符集」打开文件（常是 GBK 或 ISO-8859-1），哪怕你用 VS Code 保存为 UTF-8 无 BOM，它也大概率误判。
- 右键连接 → 「运行 SQL 文件」→ 选中你的
.sql文件 → 弹窗右上角点「编码」按钮 - 明确选
UTF-8（不是「自动检测」，也不是UTF-8 with BOM，除非你确认文件带 BOM） - 如果文件由 Windows 记事本保存，选
UTF-8 with BOM；由 VS Code / Sublime / IntelliJ 保存，默认选UTF-8 - 导入失败后别反复重试：缓存可能已污染，需关闭 Navicat 并清空
%AppData%\PremiumSoft\Navicat\Cache
脚本开头必须加 SET NAMES utf8mb4
即使文件编码选对了，Navicat 执行时仍可能沿用连接初始化时的旧字符集（比如 latin1）。尤其当脚本里含 CREATE TABLE 或 INSERT 中文字符串时，服务端会按错误 client 编码解析字节。
- 在
.sql文件最顶部第一行插入：SET NAMES utf8mb4; - 不要写
SET NAMES utf8：MySQL 的utf8不支持 emoji 和部分生僻汉字，utf8mb4才是完整 UTF-8 - 删掉脚本里所有类似
SET NAMES latin1、SET character_set_client = gbk这类覆盖性语句 - 验证是否生效：导入后立即执行
SHOW VARIABLES LIKE 'character\_set%';，确认character_set_client、character_set_connection、character_set_results全是utf8mb4
表结构本身必须用 utf8mb4，否则脚本执行完仍是乱码
脚本里建表语句若没显式声明字符集，MySQL 会继承库级甚至 server 级默认值。而老库/老表很可能还是 latin1 或 utf8，这时即使脚本执行成功，字段存的仍是错编码的字节。
- 检查建表语句末尾是否有：
DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci - 字段级也要盯紧：比如
name VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci - 已有库未设对？运行：
ALTER DATABASE `your_db` CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci; - 已有表未设对？运行：
ALTER TABLE `your_table` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;（注意：大表慎用，会锁表）
避免自动化流程中启用 SQL 预处理
Navicat 16+ 默认开启 SQL 预处理（路径：工具 → 选项 → SQL 编辑器），它会对脚本里的字符串做 Unicode 转义（如把 '张三' 变成 '\u5f20\u4e09'），MySQL 原生不认这种语法，直接报错或存空。
- 务必取消勾选：
启用 SQL 预处理 - 该选项只影响「编辑器内执行」，但若你用 Navicat 自动化任务调度执行脚本，且任务底层调用了编辑器引擎，同样会触发
- 替代方案：改用命令行
mysql -h -u -p --default-character-set=utf8mb4 db_name 更可控
真正容易被忽略的是：脚本文件编码、连接层字符集、表结构字符集这三层必须全部对齐，缺一不可。很多人只改了其中一两处，结果测试时偶尔正常、偶尔乱码，其实是靠运气匹配上了某个中间状态。
