导出超大数据库时 Navicat 卡死或报错 Out of memory
mac 版 navicat（尤其是 premium 16/17）在导出 >500mb 的 sql 文件时，常因 java 虚拟机内存不足直接卡住、无响应，或弹出 java.lang.outofmemoryerror: java heap space。这不是你数据库有问题，而是 navicat 默认堆内存仅 512mb，且 macos 对 gui 应用内存限制更严格。
根本解法不是“等它跑完”，而是绕过单文件导出瓶颈：
- 不选“转储 SQL 文件 → 结构和数据”这种一键全量方式
- 改用“导出向导（Export Wizard）”，手动分表导出，每张表单独生成
.sql文件 - 对大表（如日志表、历史记录表）跳过导出，或只导结构 + 前 10 万行数据：
SELECT * FROM large_table LIMIT 100000
用“导出向导”替代“转储 SQL 文件”实现分卷导出
“转储 SQL 文件”是单进程、不可中断、无法控制 chunk 大小的黑盒操作；而“导出向导”支持按表粒度导出，可自由组合、跳过、限行，更适合超大库。
操作路径：右键数据库 → 导出向导 → 选择“SQL 文件”格式 → 下一步 → 在“选择表”页，取消勾选明显的大表（如 logs_2024、history_archive）→ 对保留的表，点击“设置”按钮，勾选 仅导出前 N 行（建议填 50000）→ 完成后生成多个独立 .sql 文件，而非一个巨型文件。
注意：导出向导 不会自动拼接 CREATE DATABASE 和 USE 语句，导入时需手动建库并执行 USE your_db; 再逐个运行文件。
调整 Navicat 启动参数增大 JVM 堆内存（仅限 Intel Mac）
Apple Silicon（M1/M2/M3）Mac 上修改 JVM 参数基本无效（Navicat 使用 Rosetta 2 运行，参数传递不可靠），但 Intel Mac 可尝试：
关闭 Navicat，打开终端，执行：
defaults write com.premiumsoft.navicat.Premium "JVMOptions" "-Xms1024m -Xmx2048m"
然后重启 Navicat。该命令将初始堆设为 1GB、最大堆设为 2GB。若仍失败，说明问题不在内存，而在 Navicat 自身导出逻辑对大事务的处理缺陷——此时必须回归分表导出。
验证是否生效：启动 Navicat 后，菜单栏 → Navicat → 关于 Navicat → 点击版本号 3 次，会弹出 JVM 信息，检查 MaxHeapSize 是否接近 2048m。
导入分卷 SQL 文件时避免字符集错乱与权限错误
分卷导出后导入，最容易出问题的不是数据丢失，而是三处隐性断点：
- 每个
.sql文件开头没带SET NAMES utf8mb4;，导致中文变???—— 手动在每个文件第一行插入该语句 - 文件里含
CREATE TABLE但没DROP TABLE IF EXISTS，重复导入会报Table 'xxx' already exists—— 用脚本批量加前缀：sed -i '' '1s/^/DROP TABLE IF EXISTS `table_name`;\n/' file.sql（替换table_name为实际名） - Navicat 导入时默认以当前连接用户执行，若该用户无
LOCK TABLES权限（常见于云数据库只读账号），会卡在“正在执行”不动 —— 改用命令行导入：mysql -u user -p -D target_db
真正棘手的永远不是“怎么导出”，而是导出后的文件是否能被干净、可复现地还原——分卷导出看似多几步，实则把不可控的大操作，拆成了可验证、可重试、可审计的小单元。
