Navicat备份卡在99%是mysqldump正处理大字段或BLOB数据，非界面假死；主因是max_allowed_packet过小、服务端wait_timeout超时断连或SSH隧道不稳定，需调参、分表导出或改用mysqldump命令行直连。
Navicat 15卡在99%不是假死，是mysqldump正在处理大字段
进度条停在99%时，navicat界面没响应，但后台 mysqldump 进程仍在运行——它正逐行读取含 text、blob、mediumtext 的记录。单条记录超1mb、表行数多、max_allowed_packet 又没调大时，网络包反复重传或服务端直接断连，客户端就“挂”在最后几行上。
常见现象包括：CPU 占用低于 15%、磁盘IO无明显波动、任务管理器里 Navicat 进程状态为“正在运行”，但鼠标悬停进度条无响应。
必须检查 MySQL 服务端的 wait_timeout 和 max_allowed_packet
Navicat 备份/导入底层调用的是 mysqldump，而它对服务端参数极其敏感。哪怕客户端设置再合理，这两个参数没调，照样卡住：
-
max_allowed_packet默认仅 4MB，导入含长文本的 INSERT 语句时，服务端直接拒绝接收，报错MySQL server has gone away，但 Navicat 不显示该错误，只卡住 -
wait_timeout和interactive_timeout默认 28800 秒（8小时），看似够用；但 mysqldump 在写入阶段可能长时间不发查询，服务端判定空闲后主动 KILL 连接，Navicat 却还在等响应 - 修改位置必须是
[mysqld]段下，例如：[mysqld] max_allowed_packet = 512M wait_timeout = 86400 interactive_timeout = 86400
改完需重启 MySQL 服务才生效
别信“忽略错误继续执行”，先关掉 Navicat 的压缩备份
Navicat 的「压缩备份文件」选项会强制把整个导出流先缓存到内存再压缩，遇到大字段时极易触发 OOM 或阻塞 stdout/stderr 管道。尤其走 SSH 隧道时，压缩 + 隧道延迟 + 零星丢包，会让 mysqldump 输出不连续，Navicat 主进程轮询超时后彻底挂起。
实操建议：
- 右键数据库 →「备份数据库」→ 在弹出窗口中取消勾选
压缩备份文件 - 若必须全库导出，在「Additional options」里手动加参：
--max-allowed-packet=512M --skip-extended-insert -
--skip-extended-insert很关键：避免单条 INSERT 包含上万行值，导致单次网络包远超max_allowed_packet
99%卡顿最常被忽略的场景：SSH 隧道不稳定
当 Navicat 通过 SSH 连接远程 MySQL 时，它实际启动了三层进程：Navicat GUI → ssh client → mysqldump → MySQL server。任意一层通信异常都会表现为卡在99%：
- 本地
ssh_config没配ServerAliveInterval 30，隧道静默超时后中断 - 公网延迟 >100ms 或丢包率 >0.5%，mysqldump 的 stderr 输出碎片化，Navicat 解析日志失败，无法更新进度
- 更稳妥的做法是绕过 Navicat GUI，直接在终端跑：
mysqldump -h 127.0.0.1 -P 3307 -u root -p --max-allowed-packet=512M --net-read-timeout=3600 --net-write-timeout=3600 mydb > dump.sql
其中-P 3307是本地映射的 SSH 端口
真正难排查的，是服务端日志里那条不起眼的 Aborted connection ——它不会弹窗，不会报错，只会让进度条永远停在99%。
