navicat 还原进度条长时间不动通常因i/o、cpu或网络阻塞导致状态同步失败，而非软件卡死；其“正在解压”等提示仅为粗略映射，实际需串行完成aes解密+lz4解压再导入，且不读取子进程实时输出流。
navicat 还原进度条长时间不动，大概率不是软件卡死，而是底层操作被 i/o、cpu 或网络阻塞，且 navicat 无法及时获取子进程状态反馈。它显示的“正在解压”“正在还原数据库”等提示，只是对后台任务的粗略映射，不等于真实进度停滞。
还原卡在“正在解压”（.psc 文件）
这是 Navicat 自研 .psc 格式的典型表现：它必须先完整解密（AES）+ 解压（LZ4）到临时目录，再导入数据库。整个过程是串行阻塞的，且不支持流式处理。
- 检查磁盘活动：打开任务管理器 →「性能」→「磁盘」，若占用率长期 ≥95%，而
navicat.exe的 CPU 占用 - 确认临时目录位置：
C:\Users\{用户名}\AppData\Local\Navicat\Temp（Windows）或~/Library/Caches/Navicat/Temp（macOS），避免其落在机械硬盘、OneDrive 同步文件夹或 APFS 加密卷上 - 不要依赖界面“暂停/继续”按钮——
.psc解压不可中断，强行关闭会导致临时文件残留，下次启动仍可能卡住
还原卡在“正在还原数据库”（SQL Server .bak 文件）
Navicat 此时只是调用 SQL Server 的 RESTORE DATABASE 命令，真正干活的是 sqlservr.exe。卡在 70%–95% 阶段，通常是页校验（CHECKSUM）、尾日志扫描或 tempdb 写入瓶颈。
- 直接连 SSMS 或用
sqlcmd执行裸命令验证：RESTORE DATABASE [db] FROM DISK = 'x.bak' WITH RECOVERY, STATS = 5, CHECKSUM;—— 若同样卡住，问题与 Navicat 无关 - 查 SQL Server 错误日志：搜索
IO taking longer than 15 seconds或stalled IO，定位磁盘延迟；若出现Page restore started后无后续，说明正在做物理页校验 - 禁用校验仅限可信环境：
WITH NO_CHECKSUM可跳过耗时校验，但会牺牲数据完整性保障
如何判断任务是否真失败，还是假卡住？
不能只看 Navicat 界面右下角的状态栏。它的“已运行”“已完成”常滞后甚至误报，关键要看系统级日志和进程行为。
- Windows 下打开
taskschd.msc→ 找到对应 Navicat 任务 →「历史记录」选项卡 → 查看最后几条记录的「操作代码」：0x0是成功，0xC0000022是权限拒绝，0x1是路径或命令不存在 - Linux/macOS 用户若用 Wine 运行 Navicat，计划任务依赖功能基本不可用——Wine 不模拟 Windows Task Scheduler 服务，所有“定时还原”任务实际不会触发
- 用终端观察子进程：
ps aux | grep -i "sqlcmd\|mysqldump\|restore"，若进程存在且%CPU>0，说明还在跑；若进程消失但 Navicat 界面没更新，就是状态同步失败
最易被忽略的一点：Navicat 的还原进度条根本不读取子进程的实时输出流，它靠轮询临时文件大小或固定延时来估算。哪怕 mysqldump 已写完 99% 数据，只要最后一行 INSERT 没 flush 到磁盘，Navicat 就可能卡在 99% 不动——这不是 bug，是设计使然。
