Linux版Navicat导入SQL前必须显式设置SET NAMES utf8mb4；需在连接高级设置中勾选Use Unicode UTF-8并手动填入Initial command：SET NAMES utf8mb4;，同时清理SQL文件的CRLF、BOM和Windows路径注释，禁用自动编码检测，确保首行即为该命令。
Linux版Navicat导入SQL前必须显式设置SET NAMES utf8mb4
Navicat在Linux上执行SQL文件时，编码下拉菜单只控制文件读取解码，不改变MySQL连接层的字符集。即使你选了UTF-8，若连接没初始化字符集，遇到中文或emoji仍会报Incorrect string value。根本原因不是文件乱码，而是服务端收到的是latin1上下文里的字节流。
实操建议：
- 连接属性 → 「高级」页中，务必勾选
Use Unicode UTF-8 - 在同一页面的
Initial command框里，**手动填入**：SET NAMES utf8mb4;（不能少分号，不能用注释包住） - 该命令必须位于SQL文件第一行之前生效——所以文件开头不能有空行、BOM或任何不可见字符
Windows导出的SQL文件在Linux上执行前必须清理三大Windows痕迹
Navicat for Windows导出的SQL文件默认带CRLF换行、可能含UTF-8 BOM、且注释常含C:\path\to\file.sql这类绝对路径。Linux MySQL客户端（包括Navicat自身）不会自动转换这些，轻则报语法错误，重则跳过整段DDL。
必须逐项清理：
- 换行：用
dos2unix backup.sql转为LF；或VS Code打开 → 右下角编码 →Save with Encoding→UTF-8 (no BOM) - BOM：VS Code保存时确认无BOM；或用
xxd backup.sql | head检查开头是否含ef bb bf - Windows路径注释：全局搜索替换掉所有
-- Source: C:\类注释，改成-- Source: /home/user/，否则某些解析器会把\t识别为制表符导致错位
合并多个SQL文件时USE语句和DELIMITER必须人工对齐
Navicat不支持直接批量执行多个.sql文件，常见做法是用cat合并。但合并后若各文件都含USE database_name;或未闭合的DELIMITER $$，会导致后续语句在错误库执行或语法解析中断。
关键动作：
- 只保留第一个文件开头的
USE，其余文件中的USE整行删除 - 检查每个文件末尾是否有
DELIMITER ;；若某文件以DELIMITER $$开头但没配对收尾，必须手动补上DELIMITER ;再合并 - 合并后用
head -n 5 all_in_one.sql确认首行是/*!40101 SET NAMES utf8mb4 */;或SET NAMES utf8mb4;，前面不能有任何内容
别信“自动检测编码”，Linux版Navicat的编码识别逻辑极不稳定
Linux版Navicat（尤其是v16/v17）在导入时若开启「自动检测编码」，大概率把UTF-8 BOM文件识别为ISO-8859-1，结果中文全变?，且错误提示指向表名不存在——实际是解析阶段就已损坏。
稳妥做法只有两个：
- 彻底禁用「自动检测」，手动指定
UTF-8（注意：这只是文件读取层，仍需配合Initial command） - 导入前先在终端运行
locale | grep UTF-8，如果不是en_US.UTF-8或zh_CN.UTF-8，临时执行export LANG=en_US.UTF-8
最易被忽略的一点：Navicat对UTF-8 with BOM的支持极差，哪怕只多一个BOM头，就可能触发Unknown character set: 'utf8mb4'——这个报错和字符集本身无关，纯粹是BOM干扰了第一行指令解析。
