Mac版Navicat 17打开Win导出的SQL文件乱码，根本原因是Windows默认用GBK（编码936）保存，而Navicat 17 for Mac默认按UTF-8（65001）读取；解决方法是执行SQL文件时在弹窗中手动将编码改为936（GBK）或1200（UTF-16 LE），并勾选“执行前显示SQL内容”预览验证。
Mac版Navicat 17打开Win导出的SQL文件乱码？先确认编码再选
Mac上直接双击用Windows记事本或Notepad++保存的.sql文件，大概率中文变问号或方块——不是Navicat坏了，而是Windows默认用GBK或GB2312编码，而Mac系统和Navicat 17默认按UTF-8（即编码值65001）读取。你看到的“乱码”，其实是编码错配。
解决方法很简单：
- 在Navicat中右键数据库 →
运行SQL文件→ 选中文件后，**不要急着点“开始”** - 看弹窗底部的“编码”下拉框，默认是
65001 (UTF-8)，把它改成936 (GBK)或932 (Shift_JIS)（如果原文件是日文环境导出） - 点“开始”前先勾选“执行前显示SQL内容”，预览是否中文正常；若仍乱码，可试
1200 (UTF-16 LE)（常见于Windows PowerShell导出）
Navicat 17 for Mac执行Win脚本报“Unknown character set: 'utf8mb4'”？关掉建库语句就行
Windows环境下用MySQL 5.7+导出的.sql文件，开头常带CREATE DATABASE ... DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci这类语句。Mac版Navicat 17连接老版本MySQL（如5.6或MariaDB 10.2以下）时，会卡在这行报错，因为utf8mb4_0900_ai_ci是MySQL 8.0才引入的排序规则。
别删整段建库语句，只动关键部分：
- 用文本编辑器（如VS Code）打开SQL文件，找到
CREATE DATABASE那一行 - 把
DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci替换成DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci - 如果目标库已存在，更稳妥的做法是：**全选并删除从
CREATE DATABASE到第一个USE `xxx`之间的所有建库/删库语句**，只保留建表和插入数据部分
导入中途卡住或报“Packet too large”？这不是Mac性能问题，是服务端没调参
Mac版Navicat 17本身不处理SQL执行逻辑，它只是把语句发给MySQL服务端。你在Mac上看到“进度条不动”“提示超时”“报Packet too large”，99%是MySQL服务端参数太保守，尤其当你导入的是Windows下用mysqldump导出的含长BLOB或大批量INSERT的文件。
必须登录MySQL服务器改配置（不是改Navicat！）：
- 编辑
/usr/local/etc/my.cnf（macOS Homebrew安装）或/etc/my.cnf（手动安装），在[mysqld]段下加： -
max_allowed_packet=512M（至少256M，避免Packet too large） -
innodb_buffer_pool_size=2G（设为物理内存的50%，Mac M1/M2建议≥2G） - 改完重启MySQL：
brew services restart mysql或sudo launchctl kickstart -k system/com.oracle.oss.mysql.mysqld - 验证是否生效：在Navicat查询窗口执行
SHOW VARIABLES LIKE 'max_allowed_packet';
为什么“运行SQL文件”在Mac上比Windows更易中断？GUI进程内存限制是硬伤
Navicat for Mac底层是Java应用，而macOS对单个Java进程的堆内存默认限制较严。当导入>300MB的SQL文件时，Navicat会尝试把整个文件读进内存再分句，极易触发java.lang.OutOfMemoryError，表现就是界面假死、进度条卡在99%、或突然退出。
绕过这个限制只有一招：不走GUI，走命令行。哪怕你在Mac上，也该切到终端执行：
mysql -h 127.0.0.1 -P 3306 -u root -p your_db_name- 确保
your_db_name已存在且字符集正确（用utf8mb4） - 如果SQL里有
CREATE DATABASE，先去掉，或改用mysql -e "CREATE DATABASE ..."单独建库 - 大文件建议加
--default-character-set=utf8mb4参数，避免客户端层二次编码错乱
真正麻烦的从来不是跨平台，而是把“文件来源是Windows”当成万能归因——实际瓶颈往往在MySQL服务端配置、字符集链路断点、或Navicat自身Java进程的内存天花板。这三个地方没调好，换什么系统都一样慢。
