Mac版Navicat导入大SQL文件卡死的根本原因是Electron架构内存限制（默认约512MB），导致超200MB文件在解析阶段卡住；应优先改用命令行或「运行SQL文件」路径，而非调内存参数。
mac 版 navicat 导入大 sql 文件卡死，根本不是 macos 独有 bug，而是 electron 架构在内存受限环境下加载全文本 + 逐条执行的必然结果。直接换命令行或改用「运行 sql 文件」路径，比调内存参数更可靠。
为什么 Mac 上特别容易卡死
Navicat for Mac 基于 Electron，主进程默认堆内存上限约 512MB（即使你给系统分配了 32GB 内存）。一旦 SQL 文件超 200MB，它就会在解析阶段卡住：光标不动、菜单灰掉、Activity Monitor 显示 navicat 进程 CPU Ctrl + C 都无法响应。
- macOS 的 ASLR（地址空间布局随机化）和沙盒机制会让 Electron 内存分配更保守，
-Xmx1024m这类 JVM 参数在 Mac 版完全无效 - Finder 路径含中文或空格（如
/Users/张三/Downloads/backup.sql）时，Navicat 会静默解码失败，表现为“选择文件后无反应” - macOS 默认终端用 zsh，但 Navicat 内置命令行（F6）仍走 bash 环境，
mysql --version可能报错，导致你以为没装客户端
必须用「运行 SQL 文件」，别双击打开
双击 .sql 文件 → 走查询编辑器 → 全文加载进内存 → 必卡。正确路径只有一条：右键目标数据库 → 运行SQL文件 → 选文件 → 关键勾选项提前设好。
-
执行前验证SQL语法必须关闭（在工具 → 选项 → SQL 编辑器中设置，该设置只对当前 session 生效） -
每个文件作为一个事务别勾——大文件开一个事务容易撑爆innodb_log_file_size或触发max_allowed_packet - 文件路径必须是纯 ASCII，移到
/tmp/backup.sql或/Users/yourname/sql/下再试 - 如果文件头有
/*!40101 SET ... */这类 MySQL 注释，删掉——Navicat 批量执行器会把它当语法错误截断
导入前必须调服务端参数，否则卡在“正在连接”
就算 Navicat 走对了路径，max_allowed_packet 不够大，MySQL 服务端收到第一条超长 INSERT 就直接断连，Navicat 表现为“进度条动一下就停”，日志里看不到错误，因为连接已无声关闭。
- 先连上库执行：
SHOW VARIABLES LIKE 'max_allowed_packet';，确认值至少为1073741824（1GB） - 临时生效：
SET GLOBAL max_allowed_packet = 1073741824;，执行后必须关掉当前查询窗口重开连接 - 永久生效：改
/usr/local/etc/my.cnf（macOS Homebrew 安装）或/etc/my.cnf，在[mysqld]段加max_allowed_packet = 1G，然后sudo brew services restart mysql - 别漏掉
innodb_buffer_pool_size：设为物理内存的 50%～75%，比如 16GB 机器写innodb_buffer_pool_size = 8G，否则大批量 INSERT 会疯狂刷盘卡住
超过 500MB 就别硬扛，改用 mysql 命令行
Navicat 在 Mac 上处理 500MB+ 文件成功率低于 30%。命令行不走 Electron 内存池，由 mysqld 直接流式读取，实测耗时减少 60% 且零崩溃。
- 终端执行：
mysql -u root -p your_database_name < /tmp/backup.sql（注意是<，不是-e） - 如果提示
Packet for query is too large，先连进去执行SET GLOBAL max_allowed_packet = 1073741824;，再退出重试 - 路径含空格？用单引号包住：
mysql -u root -p testdb < '/tmp/big file.sql' - 中途出错想跳过？加
--force参数：mysql -u root -p --force your_db < /tmp/backup.sql
真正容易被忽略的是：Navicat 卡死时，你其实在跟 Electron 的内存模型搏斗，而不是跟 MySQL 较劲。越早切到命令行，越早省下两小时重试时间。
