navicat 不支持定时执行 sql 脚本；其计划任务仅限备份、同步等预设操作，无“运行 sql 文件”选项；可行方案为：①数据库原生调度器（如 mysql event、pg_cron）；②系统级定时任务调用 mysql 命令执行 sql 文件。
Navicat 本身不支持定时执行 SQL 脚本
直接说结论：Navicat 没有内置的“定时任务调度器”，计划任务 功能仅限于备份、同步、数据传输等预设操作，不支持自定义 SQL（尤其是多表 JOIN UPDATE）的周期性执行。你点开「计划」→「新建计划」，选来选去都找不到「运行 SQL 文件」或「执行查询」选项——这不是你没找对，是它真没有。
真正可行的替代路径只有两条
想让多表联合更新自动跑起来，得绕过 Navicat 的界面限制，用外部机制触发。常见且稳定的做法就两个：
- 用数据库原生调度器：MySQL 5.7+ 支持
EVENT，PostgreSQL 用pg_cron扩展，SQL Server 用 SQL Agent —— 这是最轻量、最贴近数据层的方式 - 用操作系统级定时任务：Linux 上写个
mysql命令脚本 +cron，Windows 上用Task Scheduler调用mysql.exe -e "UPDATE ..."—— 适合已有运维习惯、权限可控的环境
注意：
Navicat 的「批处理作业」不是定时器，它只是把多个操作串起来手动点一次执行，不能设 cron 表达式。 <h3>如果非要用 Navicat 触发，只能靠「外部命令 + 计划任务」桥接</h3> <p>Navicat 提供了命令行工具 <code>navicat.exe</code></p>（Windows）或
navicat（macOS），但它只支持打开连接、导出、备份等有限动作，不支持传入 SQL 字符串或文件执行 UPDATE。所以所谓“用 Navicat 定时”，本质是：
- 把你的多表联合更新逻辑写成独立 SQL 文件（比如
update_sales_and_inventory.sql） - 用系统定时任务（
cron或 Windows 任务计划）调用数据库客户端，例如：mysql -u root -p'pass' -h 127.0.0.1 -P 3306 mydb - 确保该 SQL 文件里用的是标准语法：MySQL 不允许在
UPDATE ... JOIN中直接给被 JOIN 的表起别名后更新（会报Error 1093），得套一层子查询或改用多表 UPDATE 语法
容易被忽略的关键细节
多表联合更新一旦进定时场景，下面三点几乎必踩坑：
-
EVENT默认关闭：MySQL 需先执行SET GLOBAL event_scheduler = ON;，且该设置重启失效，得写进my.cnf - 事务安全：定时脚本若没显式加
BEGIN; ... COMMIT;，遇上部分失败会留脏数据；但 MySQL 的EVENT无法跨语句自动开启事务，得在 SQL 里自己包住 - 锁与并发：凌晨跑的更新如果涉及大表，可能阻塞白天业务查询；建议加
LIMIT分批更新，或用WHERE updated_at 控制范围
别指望 Navicat 界面点几下就搞定定时多表更新——它只是个客户端，真正的调度和健壮性得靠数据库自身能力或系统层配合。
