Na vicat 不支持跨库自动清理，需用 Windows 自带 forfiles 命令配合任务计划程序定时执行脚本，按路径逐个清理 .nb3 文件，并须配置最高权限、避免中文路径、同步更新路径及添加日志验证。

Na vicat 本身不支持跨库自动清理，必须靠外部脚本驱动

如果你指望在 Na vicat 的菜单里找到一个“一键清理所有旧备份”的按钮，那恐怕要失望了。Na vicat 的“计划任务”功能，核心职责是备份，至于删除？它基本不管。甚至，某些老版本里那个“默认3天自动删除”的选项，也常常只是个界面上的“摆设”，底层压根没有触发任何删除逻辑。所以，想要清理分散在多台服务器、多个数据库里的旧 .nb3 备份文件，唯一的出路就是自己动手写脚本，然后交给 Windows 的任务计划程序去定时执行。

这背后的原因其实很直观：Na vicat 生成的备份文件，其存放路径是严格按照连接名、服务器地址、数据库名这样一层层嵌套下来的。比如，你可能会看到这样的结构：

• G:\Na vicat\MySQL\Servers\prod-10.20.30.40\cms
• G:\Na vicat\MySQL\Servers\test-10.20.30.41\user_center
• D:\bak\mysql\fs\fs（这是你自定义的路径）

这些路径彼此独立，互不相干。Na vicat 本身并没有提供一个统一的入口，让你能一次性扫描所有这些目录，并根据时间规则进行批量删除。因此，别再浪费时间在 Na vicat 的设置界面里寻找那个不存在的“全局清理”选项了。

用 forfiles 脚本一次性清理多个路径下的 .nb3 文件

那么，具体怎么做呢？一个轻量且稳定的方案是使用 Windows 自带的 forfiles 命令。它无需安装任何第三方工具，天生就适合这种定时清理的场景。关键操作在于，你需要为每一个需要清理的数据库备份路径，都单独写上一行 forfiles 命令。同时，务必确保路径中不包含中文或特殊字符，否则脚本会直接罢工。

下面是一个可以直接拿来用的 del_old_backups.bat 批处理文件示例（保存时请注意编码，选择 ANSI 或 UTF-8 without BOM）：

rem 清理生产环境 cms 数据库备份（7天前）
forfiles /p "G:\Na vicat\MySQL\Servers\prod-10.20.30.40\cms" /m "*.nb3" /d -7 /c "cmd /c del @path"

rem 清理测试环境 user_center 数据库备份（5天前）
forfiles /p "G:\Na vicat\MySQL\Servers\test-10.20.30.41\user_center" /m "*.nb3" /d -5 /c "cmd /c del @path"

rem 清理自定义路径 fs 数据库备份（3天前）
forfiles /p "D:\bak\mysql\fs\fs" /m "*.nb3" /d -3 /c "cmd /c del @path"

这里有三个细节需要特别警惕：

• 路径必须“纯洁”：/p 参数后面的路径，必须是全英文、无空格、尤其不能有中文。哪怕路径里只出现一个“测试”或“备份”这样的汉字，forfiles 命令就会报出诸如 ‘forfiles’ 不是内部或外部命令 或 错误: 目录名称无效 这类让人摸不着头脑的错误。
• 时间参数是反直觉的：/d -7 表示的是“早于当前日期7天”的文件，而不是我们通常理解的“超过7天”。这是 Windows 原生命令的固定语法，记住就好。
• 脚本要一气呵成：每行命令末尾不要画蛇添足地加 exit，否则后面的命令就永远不会执行了。同时，避免在脚本中使用 CHOICE 这类需要人工交互的命令，因为在任务计划无人值守的环境下，它会直接导致脚本卡死。

Windows 任务计划中必须勾选「使用最高权限运行」

脚本写好了，直接双击运行可能没问题，但一旦交给 Windows 任务计划程序，坑就来了。Na vicat 的默认备份路径通常在当前用户的文档目录下（例如 C:\Users\YourName\Documents\Na vicat\...）。而 Windows 任务计划默认是以较低的系统权限运行的，对于这些用户目录下的文件，很可能只有读取权限，没有删除权限。结果就是，任务历史记录里显示“运行成功”，但磁盘上的 .nb3 文件一个都没少。

正确的配置姿势是这样的：

• 在任务计划程序里创建一个基本任务，设置好触发器（比如每天凌晨2点），在操作步骤中选择“启动程序”，并指向你写好的 .bat 文件。
• 任务创建完成后，关键步骤来了：在“任务计划程序库”中找到该任务，右键进入“属性”。
• 在“常规”选项卡中，务必勾选上 “不管用户是否登录都要运行” 以及 “使用最高权限运行” 这两个复选框。
• 接着，点击“更改用户或组”按钮，输入 SYSTEM 或你当前的管理员账户名，然后确认。
• 最后，点击“确定”关闭属性窗口时，系统很可能会提示你输入管理员密码（这里需要的是用于提权的凭证密码，而不一定是当前登录用户的密码）。

上面这几个环节，漏掉任何一个，都可能导致脚本在后台静默失败，让你白忙一场。

备份路径变更后，脚本必须同步更新，且建议加日志验证

事情还没完。数据库运维是动态的，Na vicat 版本升级、软件重装、连接名称修改、服务器IP地址变更……这些操作都可能导致备份文件的根路径发生变化。例如，原来的 Servers\prod-10.20.30.40 可能变成了 Servers\prod-10.20.30.42。如果你的脚本没有同步更新，它就会一直对着一个已经不存在的旧路径执行操作，既找不到文件，也不会报错。你以为自动化在默默工作，实际上它只是在“优雅地”偷懒。

因此，强烈建议在脚本中加入简单的日志功能，便于事后排查和验证。例如：

echo [%date% %time%] 开始清理 >> D:\logs\cleanup.log
forfiles /p "G:\Na vicat\MySQL\Servers\prod-10.20.30.40\cms" /m "*.nb3" /d -7 /c "cmd /c echo @file >> D:\logs\cleanup.log & del @path"
echo [%date% %time%] 清理完成 >> D:\logs\cleanup.log

这样一来，每次任务执行后，你只需要打开 D:\logs\cleanup.log 文件看一眼，就能立刻知道：脚本今天运行了吗？它找到了哪些文件？删除操作成功了吗？路径到底对不对？

说到底，最让人头疼的往往不是脚本本身写错了，而是环境已经变了，你却还蒙在鼓里，傻傻地等着“自动清理”魔法生效。