navicat for redis 不支持定时执行 save/bgsave 或监控 rdb/aof 状态，其「自动运行」模块仅适配关系型数据库；redis 相关操作需依赖外部脚本（如 redis-cli）配合系统级定时任务（cron/任务计划程序）实现。
navicat 16 本身不支持对 redis 执行定时“持久化监控”——它没有内置机制去触发 save 或 bgsave，也不能轮询检查 rdb/aof 状态。所谓“自动化脚本实现定时持久化监控”，实际只能做到：定时执行 redis 命令并记录结果，或调用外部脚本间接触发备份。核心限制在 navicat 的 redis 模块设计上。
Navicat for Redis 不提供定时执行 SAVE/BGSAVE 的功能
Navicat for Redis（含在 Navicat Premium 16.2+ 中）的「自动运行」模块仅支持 MySQL/PostgreSQL/MariaDB 等关系型数据库的备份、查询、同步等批处理作业；Redis 部分目前**不支持添加 SAVE、BGSAVE 或 CONFIG GET 类命令到批处理作业中**。你无法在「自动运行 → 新建批处理作业」里为 Redis 选择“备份”动作——该选项对 Redis 是灰色不可用的。
常见误操作现象：
- 在批处理作业窗口左侧选中 Redis 连接，右侧「可用的工作」列表为空或仅显示「连接测试」「刷新」等基础操作
- 试图拖入自定义命令，但系统不接受非 SQL/DDL 类指令
- 保存后计划始终不执行，日志里无 Redis 相关输出
可行替代方案：用「运行命令文件」+ 外部脚本间接达成
Navicat for Redis 支持「运行命令文件」功能，但它只负责发送命令文本到 Redis 服务器，并不调度时间。要实现“定时”，必须依赖操作系统级任务调度器（如 Windows 任务计划程序、Linux cron），配合一个能连接 Redis 并执行命令的脚本。
实操建议：
- 写一个 Bash/PowerShell 脚本，用
redis-cli发送BGSAVE并检查LASTSAVE返回值，例如：redis-cli -h 127.0.0.1 -p 6379 BGSAVE && redis-cli -h 127.0.0.1 -p 6379 LASTSAVE
- 将脚本保存为
redis_backup.sh（Linux）或redis_backup.ps1（Windows） - 在 Navicat 中无需配置任何自动运行项；直接在 OS 层设置定时任务，比如 Linux 上：
0 2 * * * /path/to/redis_backup.sh > /var/log/redis_bgsave.log 2>&1 - 若需在 Navicat 内查看效果，可手动运行「查询」→ 输入
INFO persistence，观察rdb_last_bgsave_status:ok和rdb_last_save_time
为什么不能靠 Navicat 自带的「计划」功能监控 AOF/RDB 状态？
Navicat 的「计划」功能（即「自动运行」里的触发器）底层调用的是其内建的数据库驱动协议，而 Redis 协议不被该调度引擎识别为可“计划执行”的目标类型。即使你在连接属性里勾选了「启用自动刷新」，它也只刷新键列表或数据视图，不会执行任意命令或读取 INFO 输出。
关键差异点：
-
INFO persistence返回的是动态内存状态，Navicat 不会将其解析为监控指标，也不支持设置阈值告警 - Navicat 的「服务器监控」面板对 Redis 仅显示连接状态、响应延迟、已用内存，不包含持久化子系统字段（如
aof_enabled、rdb_changes_since_last_save） - 所有 Redis 监控类需求（如“当
rdb_changes_since_last_save > 10000时触发备份”）都必须绕过 Navicat，走redis-cli+ Shell/Python + cron 实现
真正需要“定时持久化监控”的场景，Navicat 只能充当查看终端，不能充当调度器或判断引擎。最易被忽略的一点是：很多人以为开启 Navicat 的「自动刷新」就等于开启了监控，其实它连 INFO 都不自动发——你得手动点查询按钮，或自己写脚本轮询。
