Navicat 本身不支持定时执行 SQL 刷新物化视图，其自动运行功能仅限连接时执行一次查询，无法设置间隔或循环；必须依赖数据库原生调度机制（如 PostgreSQL 的 pg_cron、Oracle 的 DBMS_SCHEDULER）实现定时刷新，Navicat 仅用于配置和执行调度语句。
Navicat 本身不支持定时执行 SQL 刷新物化视图
直接说结论：navicat 没有内置的“定时任务调度器”，它的 自动运行 功能仅限于连接成功后自动执行一次查询（比如打开连接时查个状态），无法设置间隔、循环或后台守护。想靠 navicat 界面点点点实现“每小时刷新一次 materialized view”，这条路走不通。
真正可行的替代方案是数据库原生调度 + Navicat 辅助配置
物化视图刷新必须由数据库引擎自己完成，不同数据库调度机制差异很大，Navicat 只能用来写、测、发命令，不能替数据库干活。关键看用的是哪种数据库：
- PostgreSQL：用
pg_cron扩展（需管理员安装并启用），然后执行SELECT cron.schedule('0 * * * *', 'REFRESH MATERIALIZED VIEW CONCURRENTLY my_mv;'); - Oracle：用
DBMS_SCHEDULER创建作业，例如DBMS_SCHEDULER.CREATE_JOB，类型为'PLSQL_BLOCK'，内容为REFRESH MATERIALIZED VIEW my_mv; - MySQL（8.0+）：没有原生物化视图，若用的是第三方模拟方案（如通过表+定时触发器），得依赖操作系统级调度（
crond或 Windows Task Scheduler）调用mysql -e "REFRESH ..."
Navicat 在这里只做两件事：连上库、执行建调度的 SQL（如上面的 cron.schedule）、验证作业是否注册成功（查 cron.job 表或 DBA_SCHEDULER_JOBS）。
容易被忽略的权限与并发陷阱
即使调度语句执行成功，刷新也可能静默失败——不是 Navicat 的问题，而是数据库侧权限或锁导致：
-
REFRESH MATERIALIZED VIEW CONCURRENTLY要求目标 MV 必须带唯一索引，否则报错ERROR: cannot refresh materialized view "xxx" concurrently - 非并发刷新（即没加
CONCURRENTLY）会锁住 MV 整张表，期间所有 SELECT 都会被阻塞，线上慎用 - 执行刷新的数据库用户必须有
REFRESH ANY MATERIALIZED VIEW（Oracle）或对 MV 及底层表的SELECT权限（PostgreSQL） - pg_cron 作业默认以数据库超级用户身份运行，但如果你用普通用户建 job，得显式指定
database和username参数，否则可能连错库或权限不足
调试时别只盯着 Navicat 的“执行成功”提示
Navicat 显示绿色对勾，只代表调度注册 SQL 执行完了，不代表后续定时任务真在跑。验证是否生效，必须查数据库自身调度日志：
- PostgreSQL + pg_cron：查
SELECT * FROM cron.job_run_details ORDER BY jobid, end_time DESC LIMIT 10; - Oracle：查
SELECT log_date, status, error# FROM dba_scheduler_job_log WHERE job_name = 'YOUR_JOB_NAME' ORDER BY log_date DESC; - 如果日志里全是
FAILED或STOPPED，大概率是权限、对象名拼错、或底层查询里用了不可重入的函数（比如now()在某些 MV 刷新上下文里不被允许）
最常被跳过的一步：在调度语句里把 REFRESH 包进事务块或异常捕获里——pg_cron 不支持事务控制，Oracle 的 job 默认不回滚失败，出错就停，不会重试。
