Navicat计划任务无法直接导出导入，因其保存在本地加密配置文件中；需手动重建任务，前提是新电脑已配好同名且可连通的连接，并核对时区、路径、变量及SSH/SSL等依赖项。
Navicat 计划任务本身无法直接导出导入
navicat 的「计划任务」（scheduled tasks）不提供官方导出功能，也不是独立文件或数据库对象，而是保存在本地客户端配置中（windows 下通常在 %appdata%\premiumsoft\navicat\ 或 %localappdata%\premiumsoft\navicat\ 的加密配置文件里）。这意味着你不能像导出 sql 或备份数据库那样一键迁移。
实际能迁移的只有任务逻辑本身——即连接信息、SQL 脚本、执行时间规则等。你需要手动重建，但可以大幅减少重复劳动：
- 从原电脑打开 Navicat →「工具」→「计划任务」→ 双击每个任务，复制其「连接名」「数据库名」「SQL 内容」「触发器设置（如每天 2:00）」
- 注意：如果任务使用了「运行前/后脚本」或「邮件通知」，这些字段也要一并记下
- 若连接名在新电脑上不同（比如原叫
prod-server-01，新环境叫aws-prod），后续需手动映射，不能靠名称自动匹配
连接信息必须提前在新电脑上配好
计划任务依赖已存在的连接。如果新电脑上没有同名连接，或连接参数（主机、端口、认证方式）不同，任务即使创建成功也无法执行，会报错 Connection not found 或 Failed to connect to database。
建议操作顺序：
- 先在新电脑的 Navicat 中新建所有对应连接，并确保测试连接成功
- 连接名尽量与原环境一致（大小写敏感，Navicat 会严格匹配）
- 特别注意：如果原连接用了 SSH 隧道或 SSL，新电脑的密钥路径、证书位置必须可访问，否则任务启动时会卡住或静默失败
SQL 脚本和变量引用要检查兼容性
Navicat 计划任务里写的 SQL，可能包含客户端特有语法或变量（比如 $DATE$、$TIME$、$USER$）。这些变量只在 Navicat 运行时替换，迁移到新环境后不会自动失效，但要注意：
-
$DATE$格式默认是YYYY-MM-DD，但如果脚本里拼接成'20240101'，而新系统区域设置不同，可能引发日期解析错误 - 如果 SQL 中硬编码了本地路径（如
LOAD DATA INFILE 'C:\temp\dump.csv'），必须改成新电脑上的有效路径，否则报错File not found - 某些函数（如
NOW()、CURRENT_TIMESTAMP）行为取决于目标数据库，不是 Navicat 本身问题，但容易误判为迁移导致
触发时间与系统时区影响真实执行时刻
Navicat 计划任务的「每日 9:00 执行」是按本地系统时区解释的。如果两台电脑时区不同（比如原电脑是 UTC+8，新电脑是 UTC+0），任务会在新电脑的 9:00（UTC）执行，相当于原时区的 17:00 —— 看起来“时间偏移了”。
解决方法很简单，但常被忽略：
- 确认新电脑系统时区设置是否符合业务预期（控制面板 → 时钟和区域 → 时区）
- 不要依赖 Navicat 界面显示的“9:00”，而应看任务日志里的实际触发时间戳（右键任务 →「日志」）
- 如果必须跨时区统一调度，建议改用数据库原生定时器（如 MySQL 的
EVENT）或系统级任务（Windows Task Scheduler / cron），Navicat 仅作管理界面
真正麻烦的不是复制粘贴，而是那些没显式写出来的依赖：时区、路径、连接别名、变量上下文。漏掉一个，任务就静默失败，日志里只有一行 Task completed with error，得挨个对齐才能定位。
