navicat 16 不支持直接解析 oracle 的 .dmp 文件，必须通过 impdp/imp 命令在数据库服务器端执行；导入大 sql 文件易卡死，因默认内存加载、max_allowed_packet 过小及 mysql 缓冲配置不足，需调优 innodb_buffer_pool_size 等参数并改用命令行导入。
Navicat 16 本身不直接解析或执行 Oracle 的 .dmp 文件，也不原生支持 MySQL 的超大 .sql dump 的流式导入 —— 它依赖后端数据库服务的能力和本地环境配置。单纯点“运行SQL文件”导入 2GB+ 的文件，大概率卡死、报错或中途失败。
为什么 Navicat 导入大 SQL 文件会卡住或报错
Navicat 的“运行SQL文件”功能本质是把整个文件读入内存，再分段发给 MySQL 执行。对 2GB+ 的 dump 来说：
- 默认
max_allowed_packet=4M，遇到一条超长INSERT就触发Packets larger than max_allowed_packet are not allowed - Navicat 自身内存占用飙升（尤其 Windows 上），可能被系统杀掉或无响应
- MySQL 默认
innodb_buffer_pool_size太小（如 128MB），大量写入触发频繁刷盘和锁等待 - 未关闭 autocommit 或未调优日志刷盘策略，导致事务提交成为瓶颈
必须改的 MySQL 配置项（my.ini / my.cnf）
这些参数不是“可选优化”，而是 GB 级导入的前提。修改后需重启 MySQL 服务才生效：
-
innodb_buffer_pool_size=16G：设为物理内存的 1/4～1/2（你有 64GB 就设 16G），否则缓存不够，磁盘 IO 拖垮全程 -
max_allowed_packet=1024M：必须 ≥ dump 文件中最大单条语句长度；低于 512M 很容易在建表或大批量插入时中断 -
innodb_log_file_size=1024M：配合innodb_log_buffer_size=1G，减少 redo 日志切换和刷盘次数 -
innodb_flush_log_at_trx_commit=2：导入期间允许最多 1 秒数据延迟落盘，性能提升明显；导入完可改回 1 -
sort_buffer_size=64M和read_rnd_buffer_size=64M：加速 CREATE INDEX 阶段的排序
Navicat 16 中正确的导入操作路径
别用“导入向导”——它会尝试预读、校验、转义，对大文件就是灾难。走最简路径：
- 确保目标数据库已存在（字符集推荐
utf8mb4），且 Navicat 已连接成功 - 右键该数据库 → 选择“运行SQL文件”，不是“导入向导”也不是“导入导出来自”
- 勾选“使用其他字符集”，选
UTF8MB4（哪怕文件是 UTF8，也常因 BOM 或混合编码出错） - 取消勾选“停止执行错误语句”——有些 dump 含兼容性注释或条件判断，报错可跳过
- 点击“开始”，观察 Navicat 底部状态栏的“已执行 X 行”，而不是看进度条（它经常假死不动）
比 Navicat 更稳的替代方案（真遇到卡死时）
当 Navicat 卡在 99% 或反复断连，说明它已不是瓶颈，而是管道问题。此时应切到命令行：
- 先用
mysql --defaults-file=my.cnf -u root -D your_db ，其中 <code>my.cnf包含上述所有客户端参数（尤其是max_allowed_packet） - 若仍报
MySQL server has gone away，加参数--max-allowed-packet=1G --net-buffer-length=1M - 对 Oracle
.dmp文件：Navicat 完全无法处理，必须用impdp或imp命令，在服务器本地执行（Navicat 只能连上去查结果）
真正卡住的地方往往不在 Navicat 界面，而在 MySQL 的包限制、缓冲区大小和日志策略上。调参不是玄学，每个值都对应一个具体瓶颈；没改配置就硬拖大文件进去，等于让自行车拉货柜。
