Navicat 本身不支持定时清理，需依赖外部调度工具调用其命令行工具执行预存查询；必须在GUI中保存带WHERE条件的DELETE语句并确保字段有索引，生产环境须先统计再删除且禁用CLI直接上线。
Navicat 里根本不能直接设“定时清理”
navicat 是个图形化客户端，不是调度服务，它本身不提供定时任务功能。所谓“定时清理”，实际是靠外部调度（如 windows 任务计划程序、linux cron）调用 navicat 的命令行工具 navicat.exe（windows）或 navicat（macos/linux）来执行预存的查询或批处理作业。
真正能定时执行的只有 Navicat 的 CLI + 预存查询
你得先在 Navicat GUI 里写好一条 DELETE 或 TRUNCATE 语句，保存为“查询”（Query），比如叫 cleanup_logs_7days；然后用命令行触发它：
navicat.exe --run-query "MyConnectionName" "cleanup_logs_7days"
常见踩坑点：
-
MyConnectionName必须和 Navicat 连接列表里的名称**完全一致**（含空格、大小写） - 查询必须保存在“连接级”下，不能只存在“查询”标签页但未保存到该连接中
- Windows 上若 Navicat 安装在 Program Files，路径含空格，命令需加引号包裹整个路径
- CLI 执行时不会弹窗，失败也无提示——建议把输出重定向到日志：
> C:\logs\cleanup.log 2>&1
DELETE 比 TRUNCATE 更安全，但别忘加 WHERE 和索引
日志表通常数据量大，TRUNCATE TABLE 虽快，但会重置自增 ID、无法回滚、且 Navicat CLI 对它的返回状态不敏感，容易误清全表。推荐用 DELETE 并严格限定条件：
sys_log
关键注意：
- WHERE 条件字段（如
created_at）必须有索引，否则 DELETE 会全表扫描，锁表时间长 - 避免用
DATE(created_at)这类函数包裹字段，会导致索引失效 - 单次删太多行（如 >10 万）可能卡住连接，可分批次加
LIMIT 5000并循环执行
生产库清理必须绕过 Navicat 做双重确认
Navicat 的 CLI 执行没有二次确认机制，一旦脚本参数写错（比如连错库、查错表名），就是静默误删。真实生产环境应：
- 所有清理脚本开头加
SELECT COUNT(*)统计待删行数，并输出到日志 - 在调度任务里设置失败重试为 0 次，避免重复执行
- 优先用数据库原生方案替代：MySQL 可用
EVENT，PostgreSQL 可用pg_cron，它们更可靠、可观测 - Navicat 最多只用来调试语句逻辑，上线后应移出关键路径
最常被忽略的一点：Navicat CLI 的身份认证依赖本地已保存的连接密码，如果连接配置了“保存密码”，那密码就明文存在本地加密文件里——换机器、重装或权限变更后，CLI 很可能直接失败，而不是报错密码问题。
