navicat“保留n天”未清理是因仅依赖文件名标准时间戳，命名不规范、ui缓存未生效、同步盘路径等均导致清理逻辑失效；可靠方案是用forfiles按lastwritetime删除，并修改temp/tmp环境变量防c盘占满。
navicat 定时备份占满磁盘，根本不是“备份太多”，而是清理逻辑压根没生效——它只认文件名里的标准时间戳，其他一概无视。
为什么 Navicat 的“保留 7 天”根本没删文件
Navicat 自动备份任务从不主动清理旧文件，所谓“保留 N 天”只是个筛选条件，且判断依据完全依赖文件名中是否含标准时间格式（如 mydb_202407281430.nb3）。一旦命名不规范，清理就彻底失效：
- 文件名为
backup_1.nb3、prod.sql或手动重命名过 → Navicat 直接跳过，不计入计数也不参与时间判断 - 勾选了
Include timestamp in filename，但 UI 缓存未刷新（多窗口编辑后常见）→ 实际导出仍用旧命名，时间戳根本没写进去 - 备份路径含 OneDrive/iCloud/WSL 挂载点 → 文件系统枚举失败，清理流程直接中断，无报错也无日志
- 企业版加密备份
.nb3文件虽加密，但文件名和时间戳可读，不影响 forfiles 清理 —— 加密不等于不可识别
用 forfiles 命令绕过 Navicat 的清理限制
Windows 自带的 forfiles 是最轻量、最可靠的兜底方案，它不看文件名，只认 LastWriteTime —— 而 Navicat 写完备份后会正确更新这个时间戳。
-
/d -7不是“7×24 小时前”，而是“早于 7 天前的 00:00:00”，例如今天是 7月28日 03:12，它删的是 7月21日 00:00 之前修改的文件 -
/s必须加 —— 若你按项目分目录（如D:\Backups\Project_A\Daily\），不加就只扫根目录，子目录旧文件全漏掉 - 首次运行务必先用
/c "cmd /c echo @path"预览，确认匹配范围是否合理；别一上来就del @path - 路径含空格必须用英文双引号包裹整个
/p参数值，如/p "D:\My Backups\MySQL"；含中文或全角符号会报错“目录名称无效”
临时文件狂写 C 盘和备份路径无关
很多人把备份目录改成 D 盘，C 盘还是飞速掉空间，因为 Navicat 的临时文件（压缩中间段、解压缓存、校验块）默认走 Windows 的 TEMP 和 TMP 环境变量，不是备份路径设置能控制的。
- 必须在「系统变量」里修改
TEMP和TMP为非 C 盘路径，例如D:\Navicat_Temp - 手动创建该目录，并给当前用户「完全控制」权限（右键 → 属性 → 安全 → 编辑）
- 重启 Navicat 进程（包括托盘图标），建议重启系统使变量全局生效
- 验证方式：执行一次小备份，去你设的新
TEMP路径下查看是否有新生成的navicat_temp_*临时文件夹
清理脚本必须加 CHOICE 兜底返回成功码
Windows 任务计划程序会将 forfiles 无匹配时的退出码 1 识别为“失败”，导致任务状态变红、触发告警。这不是脚本问题，是调度器行为。
- 用
CHOICE /T 5 /C y /D y /n强制返回 0 退出码，避免误报；它不真正做选择，只是占位返回成功信号 - 别用
del /f /q替代del @path—— 前者对不存在的文件也返回 0，会掩盖路径错误或权限问题 - 排障时先手动运行脚本，观察控制台是否出现
ERROR: No files found—— 这说明路径或掩码写错了，不是“没删成”，而是“根本没找到”
真正卡住人的从来不是命令怎么写，而是搞不清 Navicat 到底在哪个环节“假装工作”：它既不保证命名规范，也不处理同步盘语义异常，更不会管你系统变量有没有改。所有“自动”背后，都得靠外部脚本补全逻辑断点。
