Navicat 不支持定时归档任务，需借助外部调度器调用其命令行工具执行预编写的SQL归档脚本，并确保动态时间计算、分批删除、导出路径校验及独立归档库设计。
Navicat 本身不支持定时归档任务
navicat 是数据库管理工具，不是调度服务，它没有内置的定时任务引擎。所谓“定时归档”，实际需要组合外部调度器（如 cron、windows task scheduler）和 navicat 的命令行工具 navicat.exe（windows）或 navicat（macos/linux）来间接实现。
归档逻辑必须由 SQL 脚本定义，不能靠 Navicat 点击完成
Navicat 的“自动运行”功能仅能执行预存的查询或批处理，但无法动态计算“一年前”的时间边界，也不能安全地分步完成：查出数据 → 导出 → 删除 → 验证。这些必须写成可复用的 SQL 脚本，并确保事务与错误处理。
- 推荐在目标数据库中编写存储过程（如 MySQL 的
archive_old_records），用DATE_SUB(NOW(), INTERVAL 1 YEAR)动态生成截止时间 - 避免在脚本里硬编码日期，否则每次调度都要改
- 归档前务必加
SELECT COUNT(*)校验待处理行数，防止误删 - 删除操作必须用
DELETE ... LIMIT分批次执行（例如每次 5000 行），避免长事务锁表
用命令行调用 Navicat 执行归档脚本并接入系统定时器
Navicat 提供命令行接口，可触发已保存的查询或模型。但注意：它不返回 SQL 执行结果码，失败时也未必报错，容易掩盖问题。
- Windows 示例（需先在 Navicat 中保存名为
archive_orders的查询）：navicat.exe --run-query "MyConnection" "archive_orders"
- macOS 示例：
open -a "Navicat Premium" --args --run-query "MyConnection" "archive_orders"
- 更稳妥的做法是绕过 Navicat，直接用
mysql或psql命令行工具执行归档脚本，便于捕获退出码和日志 - Linux/macOS 下用 cron，建议加上日志重定向：
0 2 * * * /usr/local/bin/archive_script.sh >> /var/log/archive.log 2>&1
归档后的数据存放和验证不能依赖 Navicat 自动保存
Navicat 的导出功能（如导出为 SQL 文件或 CSV）是交互式操作，命令行调用时若未指定完整路径和格式参数，极易失败或输出到默认临时目录，后续无法追踪。
- 导出路径必须用绝对路径，且确保运行用户有写权限（例如
/backup/orders_$(date +\%Y\%m\%d).sql） - 导出后应立即校验文件非空：
test -s /backup/...sql && echo "OK" || echo "Empty export!" - 归档表建议建在独立库（如
archive_db），而非原库加后缀，避免备份策略混淆 - 别忘了更新归档表的统计信息（如 MySQL 的
ANALYZE TABLE），否则后续查询可能走错执行计划
Navicat 只是执行入口，真正的归档健壮性取决于 SQL 逻辑设计、调度可靠性与文件落地校验——这三个环节任何一环松动，都会导致数据丢失或重复归档，而这类问题往往在半年后才暴露。
