Navicat 本身不支持定时任务调度，需借助系统级定时工具（如 cron/Task Scheduler）调用其命令行工具 ncli，或直接在数据库端配置事件（如 MySQL 的 EVENT）实现自动清理。
Navicat 本身不支持定时任务调度
navicat 是数据库客户端工具，不是任务调度器。它没有内置的「定时执行 sql」功能，所有所谓“自动清理日志”的操作，本质是借壳——要么靠操作系统级定时任务（如 cron / task scheduler）调用 navicat 命令行工具 ncli，要么把逻辑下推到数据库服务端（如 mysql 事件、postgresql 的 pg_cron 扩展）。
直接在 Navicat GUI 里点点点，不可能实现真正的定时清理。
用 ncli + 系统定时任务跑清理脚本
Navicat 提供命令行工具 ncli（Windows 下为 ncli.exe），可执行预存的查询或 SQL 文件。这是最贴近“用 Navicat 做定时清理”的可行路径。
- 先在 Navicat 中写好清理 SQL（例如：
DELETE FROM log_table WHERE create_time ），保存为查询（Query）或导出为cleanup.sql - 确认
ncli路径已加入系统 PATH，或使用绝对路径调用 - Linux 示例（crontab）：
0 2 * * * /path/to/ncli -c "MyConnection" -q "/path/to/cleanup.sql" > /dev/null 2>&1 - Windows 示例（Task Scheduler）：新建任务，触发器设为每天 2:00，操作为启动程序
ncli.exe，参数填-c "MyConnection" -q "C:\scripts\cleanup.sql" - 注意连接名
"MyConnection"必须和 Navicat 中保存的连接名称完全一致（区分大小写、空格） -
ncli不返回错误码给系统调度器，失败时可能静默跳过，建议在 SQL 中加SELECT ROW_COUNT()并重定向日志排查
更稳的做法：把清理逻辑交给数据库自身
绕开 Navicat，直接在数据库里建定时事件，可靠性高、不依赖客户端在线、权限和事务控制也更清晰。
- MySQL：启用
event_scheduler=ON，然后建事件：CREATE EVENT cleanup_logs ON SCHEDULE EVERY 1 DAY DO DELETE FROM log_table WHERE create_time - PostgreSQL：安装
pg_cron扩展后运行：SCHEDULE '0 2 * * *' DO $$ DELETE FROM log_table WHERE create_time - SQL Server：用 SQL Server Agent 新建作业，步骤类型选「Transact-SQL 脚本 (T-SQL)」
- 避免在事件中用
TRUNCATE—— 多数数据库事件不支持该语句（权限或事务上下文限制），优先用DELETE+ 索引优化 - 记得给
create_time字段建索引，否则每日扫描全表会拖慢主业务
常见报错和权限坑点
无论走 ncli 还是数据库事件，下面这些错误高频出现，且容易卡住：
-
Access denied for user 'xxx'@'localhost'：ncli 默认用连接里保存的账号密码，但事件调度器用的是定义者（DEFINER）用户，需确保该用户有DELETE权限，且对目标表不是仅SELECT -
Event scheduler is disabled：MySQL 需显式执行SET GLOBAL event_scheduler = ON，且重启后失效，要写进my.cnf -
ncli: command not found：macOS/Linux 下未加执行权限（chmod +x ncli）或路径不对；Windows 下注意是否用了中文路径或空格，建议用短路径（如C:\nav\ncli.exe） - 时间字段类型是
TEXT或VARCHAR：WHERE create_time 会隐式转换失败，查不到数据也不报错，务必确认字段是DATETIME或TIMESTAMP
真正麻烦的从来不是写那条 DELETE，而是时间精度、时区设置、索引缺失、权限链断裂——这些地方一漏，清理就变成幻觉。
