Navicat不自动清理旧备份文件，其“保留N天”功能仅依赖文件名标准时间戳识别，若命名不规范（如backup_1.nb3）、含中文路径、存于OneDrive等同步盘，或UI缓存未生效，均导致清理逻辑失效；可靠方案是用Windows forfiles命令按LastWriteTime删除，命令为forfiles /p "路径" /s /d -7 /c "cmd /c del @path"。
Navicat备份文件堆积不是“没清理”，而是清理逻辑失效
navicat 自动备份任务本身不负责按时间删旧文件，它只在「保留最近 n 个」或「保留 n 天内」两种模式下工作，且判断依据**完全依赖文件名中的时间戳**。如果备份文件名不含标准格式（如 mydb_202405121430.nb3），或者被手动重命名、外部工具生成，navicat 就会跳过清理——看起来像“没删”，实则是根本识别不了。
常见失效场景：
- 备份文件名为
backup_1.nb3、prod.sql等无时间戳命名 → Navicat 按数量保留时，只认自己生成的编号，手动放进去的不计入 - 勾选了
Include timestamp in filename，但 UI 缓存未生效（尤其多窗口编辑后）→ 实际导出仍用旧命名规则 - 备份路径含 OneDrive、iCloud 或 WSL 挂载点 → 文件系统语义异常导致枚举失败，清理直接中断
forfiles 命令删旧备份必须绕过 Navicat 的限制
Windows 自带 forfiles 是最轻量、最可靠的兜底方案，但它不看文件名，只认 LastWriteTime —— 而 Navicat 写完备份后会正确更新这个时间戳，所以可放心用。
关键参数说明和避坑点：
-
/d -7不是“7×24 小时前”，而是“早于 7 天前的 00:00:00”，比如今天是 6月11日 10:30，它删的是 6月4日 00:00 之前修改的文件 -
/s必须加 —— 若你按项目分目录（如D:\Backups\Project_A\Daily\），不加就只扫根目录 -
/c "cmd /c del @path"别替换成del /q /f——forfiles已精准定位，多一层del反而可能因权限或占用报错 - 首次运行务必先用
/c "cmd /c echo @path"预览，确认匹配范围是否合理
临时文件狂写 C 盘和备份路径无关，得改系统环境变量
很多人把备份目录改成 D 盘，C 盘还是飞速掉空间，因为 Navicat 的临时文件（压缩中间段、解压缓存、校验块）默认走 Windows 的 TEMP 和 TMP 环境变量，不是备份路径设置能控制的。
必须改系统级变量：
- 以管理员身份打开「系统属性 → 高级 → 环境变量」
- 在「系统变量」里修改
TEMP和TMP为非 C 盘路径，例如D:\Navicat_Temp - 手动创建该目录，并给当前用户「完全控制」权限（右键 → 属性 → 安全 → 编辑）
- 重启 Navicat 进程（包括托盘图标），甚至建议重启系统使变量全局生效
验证方式：执行一次小备份，去你设的新 Temp 目录下找是否有 navicat_temp_* 文件夹生成。
自动任务 OOM 和磁盘满经常同时发生，但根源不同
当 Navicat 自动备份任务卡住、报错、甚至导致 C 盘爆满，别急着删文件——先看任务类型：
- 如果是「运行 SQL 文件」类任务，它会把整个 SQL 全读进内存再解析，哪怕设置了分批，也挡不住初始加载阶段的内存暴涨
- 如果开启了「详细日志」或「保存执行结果」，每条 INSERT 的状态、堆栈、影响行数都会序列化缓存，极易撑爆 JVM 堆
- 同步任务长期持有表结构元数据快照 + 结果集缓存，后台无交互时更难触发 GC 回收
最快缓解方式：打开任务编辑界面 → 「高级」选项卡 → 取消勾选「记录详细日志」和「保存执行结果」；若用数据传输，把 Fetch Size 显式设为 500（不要留空）。
真正稳定的做法是剥离 Navicat：用 mysqldump + forfiles + Windows 任务计划组合，既避开 GUI 内存模型，又可控、可审计、不依赖进程存活。
