Navicat 还原进度条卡住不动？别慌，真相在这儿
今天聊一个让不少朋友头疼的问题：用 Navicat 还原数据库时，进度条卡住不动了。画面看似静止，但你真的遇到过它“死”掉吗？
先说结论：大概率不是软件卡死，而是底层的 I/O、CPU 或网络给堵住了。Navicat 自己也没辙，因为它在设计上不读取子进程的实时输出流——所以哪怕后台忙得热火朝天，界面可能还一脸无辜地停在“99%”。
场景一：还原卡在“正在解压”环节
如果你用的是 Navicat 自研的 .psc 格式文件，那这个大坑几乎是标配——它必须先解密（AES）、再解压（LZ4），整个过程串行且完全阻塞。中间没有任何“流式处理”的捷径，你看到“正在解压”时，其实后台正老老实实地在临时目录里逐个字节干活。
怎么办？
- 查磁盘负载：打开任务管理器，盯着“性能”标签下的磁盘占用率。如果它长期 ≥95%，而
navicat.exe的 CPU 占用却低得可怜，说明磁盘在拼命跑，慢是正常的。反之，大概率是软件层面的等待。 - 确认临时目录位置：Windows 上一般在
C:Users\{用户名}\AppData\Local\Navicat\Temp，macOS 在~/Library/Caches/Navicat/Temp。千万注意：不要让它落在机械硬盘、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 毫无关系，该去找 DBA 了。 - 看 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，而是它设计时就留下的一个“盲区”。所以下次遇到这种场景，别急着退出，多等一会儿，或者直接用系统命令验证一下再做判断。
