Navicat 不支持真正定时执行 DELETE 脚本，需依赖 MySQL 事件调度器或系统级定时任务；启用 event_scheduler 后，可创建每日清理 7 天前 operation_log 数据的自动事件。
navicat 本身不支持定时执行 delete 脚本，所谓“自动化作业”只是界面级触发器，关机、退出或用户登出即失效；真要定时清理历史数据，必须把逻辑交给数据库服务端（如 mysql 事件）或操作系统调度器（如 cron / task scheduler），navicat 最多充当 sql 编辑与脚本导出工具。
MySQL 事件调度器建自动清理作业（推荐）
这是最稳定、不依赖客户端在线的方式，适合清理 operation_log、audit_log 等按时间字段归档的表。
- 先确认调度器已启用：
SHOW VARIABLES LIKE 'event_scheduler';返回ON才能用 - 若为
OFF，需执行SET GLOBAL event_scheduler = ON;（要求SUPER权限） - 确保当前用户对目标表有
DELETE权限，且事件定义者（DEFINER）账号也具备该权限 - 建事件示例（每天删 7 天前数据）：
CREATE EVENT clean_old_logs ON SCHEDULE EVERY 1 DAY DO DELETE FROM operation_log WHERE create_time < NOW() - INTERVAL 7 DAY;
-
NOW()按服务器系统时区计算，和 Navicat 客户端时区无关；别写成CURDATE() - 7这类易错表达式
用 Navicat 写好脚本后导出为 .sql 文件
Navicat 的价值在此环节：语法高亮、执行预检、保存可复用逻辑。但导出后必须靠外部调度运行，不能指望它自己定时。
- 在查询窗口写好清理语句，例如：
DELETE FROM audit_log WHERE created_at - 点击「文件 → 另存为 → SQL 文件」，路径建议全英文、无空格（如
D:\scripts\clean_audit.sql） - 避免在脚本里写
USE mydb;—— 外部命令行调用时需显式指定库名，否则可能误删其他库同名表 - 如果表数据量大，
create_time或created_at字段必须有索引，否则每日全表扫描会拖慢主业务
Windows 任务计划程序调用 ncli.exe 执行脚本
这是唯一接近“用 Navicat 做定时”的路径，但本质是调它的命令行工具 ncli.exe，不是 GUI 功能。
- 确认
ncli.exe路径已加入系统PATH，或在任务中使用绝对路径（如"C:\Program Files\PremiumSoft\Navicat Premium 16\ncli.exe"） - 参数必须完整：
-c "MyProdDB" -q "D:\scripts\clean_audit.sql"，其中"MyProdDB"是 Navicat 中连接的**显示名称**，大小写和空格都要一致 - 任务属性 → 「常规」页必须勾选「不管用户是否登录都要运行」+「使用最高权限运行」，否则静默失败
-
ncli不返回错误码给系统，失败时无提示；建议在 SQL 文件末尾加SELECT ROW_COUNT();并重定向输出到日志文件排查 - 别用
DEL或PowerShell直接删表——那是文件系统操作，和清理数据库表数据完全无关
为什么 TRUNCATE 不建议放进事件或 ncli 脚本
看起来快，但实际埋雷多：
- MySQL 事件上下文中不支持
TRUNCATE TABLE（报错TRUNCATE is not allowed in stored functions/trigger/event） -
TRUNCATE隐式提交事务，无法回滚；在主从复制中可能造成 GTID 不一致 - 需要
DROP权限，而多数运维账号只给SELECT/INSERT/UPDATE/DELETE，权限收紧时直接失败 - 大表
TRUNCATE仍会锁表（尤其 MyISAM），InnoDB 虽快但也阻塞 DML；DELETE ... LIMIT 10000分批删更可控
真正容易被忽略的点是：所有方案都默认你已确认日志表是数据库表存储（log_output = 'TABLE'），而不是文件。 如果 slow_log 或 general_log 还在写入文件，DELETE FROM mysql.slow_log 根本查不到数据——先跑 SELECT @@log_output; 看返回值，别一上来就写事件。
