Navicat计划任务不能用于生产环境自动清理：它依赖GUI登录会话，锁屏/登出即失效；无法加载SSH/SSL等生产连接凭据；不自动提交事务导致DELETE静默回滚；无失败重试、日志归档和通知能力，强行使用等于埋雷。
navicat 计划任务不能用于生产环境的自动清理——它不保证执行、不隔离权限、不记录失败，强行用等于埋雷。
为什么 Navicat 计划任务在生产环境必然失效
Navicat 的「计划任务」功能本质是 Windows 任务计划程序调用 navicat.exe 带参数启动 GUI 进程，依赖当前用户登录会话。这意味着：
- 服务器无人值守时（如 Linux 无桌面、Windows Server 未启用交互式服务），任务根本不会启动
- 锁屏、远程桌面断开、用户登出后，任务静默失败，错误码常为
0x80070005或直接无日志 - 它无法加载 SSH 隧道、SSL 证书、密钥代理等连接前置条件，而生产库几乎都启用了这些
- 执行上下文是临时 GUI 会话，
COMMIT不自动触发，手动提交模式下DELETE看似成功实则回滚
MySQL 生产库该用 EVENT 而不是 Navicat 计划任务
真正可靠的做法，是把清理逻辑下沉到数据库服务端。前提是确认 event_scheduler 已启用：
SHOW VARIABLES LIKE 'event_scheduler'; —— 必须返回 ON，否则执行 SET GLOBAL event_scheduler = ON;（需 SUPER 权限）
建事件示例（清理 operation_log 表中 7 天前数据）：
CREATE EVENT clean_old_logs ON SCHEDULE EVERY 1 DAY DO DELETE FROM operation_log WHERE create_time < NOW() - INTERVAL 7 DAY;
关键点：
- 事件默认不启用，必须加
ENABLE或后续执行ALTER EVENT clean_old_logs ENABLE; - 确保定义者（
DEFINER）用户对目标表有DELETE权限，不能只靠 Navicat 连接里填的账号 - 避免用
TRUNCATE TABLE：它隐式提交、不可回滚，在主从复制或审计合规场景下可能被拦截 -
create_time字段必须有索引，否则每日全表扫描会拖垮业务查询
PostgreSQL / SQL Server / 云托管 MySQL 怎么办
当数据库不支持原生事件调度器（如阿里云 RDS MySQL 默认禁用 EVENT 权限），或你用的是 PostgreSQL、SQL Server，就退到系统级调度 + 命令行工具：
- PostgreSQL：用
psql+cron（Linux）或 Task Scheduler（Windows），命令形如：psql -U admin -d mydb -f "C:\scripts\clean_logs.sql" - SQL Server：用
sqlcmd+ SQL Server Agent 作业，步骤类型选「Transact-SQL 脚本 (T-SQL)」 - 云 MySQL：禁用
EVENT时，唯一可行路径是 ECS 上起mysql客户端 +cron，但密码必须走~/.my.cnf配置文件，绝不能明文写在命令里
Navicat 在这里只干一件事：帮你写好、调试并保存 clean_logs.sql，然后退出。别让它碰调度。
Navicat 自动备份生成的 .nb3 文件怎么清
Navicat 本地自动生成的 .nb3 备份文件，和数据库日志清理是两回事，必须用 Windows 原生命令处理：
标准命令（删除 7 天前的 .nb3）：
forfiles /p "D:\Navicat\Backup" /m *.nb3 /d -7 /c "cmd /c del @path"
但生产环境必须加固：
- 路径不能含中文或全角符号，否则报错
目录名称无效 - 脚本开头加
if not exist "D:\Navicat\Backup" exit /b 1，防误删根目录 - 首次运行先用
/c "cmd /c echo @path"预览，确认匹配范围 - 加
2>nul屏蔽 “找不到文件” 提示，避免任务计划程序误判失败 - 别用
del /f /q：它对不存在路径也返回 0，掩盖了真实路径错误
最易被忽略的一点：Navicat 的「自动备份」和「自动清理」完全解耦，它从不自动删自己产生的旧文件。你写的清理脚本，必须比备份任务晚至少 5 分钟触发，否则可能删掉刚生成的备份。
