定时刷新物化视图需依赖外部调度或数据库作业机制，而非语法原生支持；PostgreSQL用pg_cron插件配合CONCURRENTLY刷新，Oracle需配置job_queue_processes并正确设置START WITH/NEXT，MySQL则通过事件或双表切换模拟，且均须规避触发器实时刷新陷阱。
REFRESH MATERIALIZED VIEW 本身不是定时指令，所有数据库都不支持 REFRESH EVERY 1 HOUR 这类语法。所谓“定时刷新”，本质是靠外部调度器调用刷新命令，或靠数据库内置作业机制触发执行——不是物化视图自己会动，而是你得让它“被按时叫醒”。
PostgreSQL：用 pg_cron 插件最稳
pg_cron 是 PostgreSQL 官方推荐的轻量级调度插件，SQL 内直接写 cron 表达式，避免 shell 脚本 + psql 的权限、事务、日志割裂问题。
-
CREATE EXTENSION pg_cron需 superuser 权限，且postgresql.conf中已配置shared_preload_libraries = 'pg_cron'并重启 - 定时任务必须加
CONCURRENTLY：例如REFRESH MATERIALIZED VIEW CONCURRENTLY mv_user_summary，否则刷新期间视图不可读 -
CONCURRENTLY前提是物化视图已有唯一索引（如CREATE UNIQUE INDEX idx_mv_id ON mv_user_summary(id)），否则报错cannot refresh materialized view "xxx" concurrently, because it has no unique index - 时间表达式用标准 cron 格式，例如
'0 2 * * *'表示每天凌晨 2 点；任务名（如'refresh_mv_daily'）不能重复
Oracle：NEXT 不等于自动执行，job 必须活
NEXT TRUNC(SYSDATE) + 1 这类子句只是“记个时间点”，真正干活的是 Oracle 的 job 机制。它不跑，物化视图就永远不动。
-
job_queue_processes必须 > 0（12c+ 建议设为 1000），否则 job 队列被禁用 - 物化视图必须是
ON DEMAND模式，ON COMMIT下START WITH/NEXT完全无效 -
START WITH和NEXT必须是返回DATE类型的表达式，不能写成字符串，比如'SYSDATE + 1'会直接导致ORA-12012错误；正确写法是START WITH SYSDATE、NEXT TRUNC(SYSDATE) + 1 + 8/24（每天早 8 点） - 查
DBA_JOBS确认 job 是否注册成功；若FAILURES > 0，说明DBMS_MVIEW.REFRESH执行失败但错误被静默吞掉，需手动运行并观察报错
MySQL：没有物化视图，只能模拟
MySQL 原生无 MATERIALIZED VIEW 语法，常用做法是建一张普通表 + 定时覆盖数据。关键陷阱不在“怎么刷”，而在“怎么刷得不丢数据”。
- 别用
TRUNCATE + INSERT：中间窗口期表为空，业务查询会看到空结果 - 推荐双表切换：
CREATE TABLE mv_summary_new AS SELECT ...→RENAME TABLE mv_summary TO mv_summary_old, mv_summary_new TO mv_summary，原子性有保障 - 增量更新更高效：
INSERT INTO mv_summary (...) SELECT ... ON DUPLICATE KEY UPDATE ...，但要求物化表有主键或唯一键 - 事件调度器（
EVENT）可启用：SET GLOBAL event_scheduler = ON，然后CREATE EVENT refresh_mv ON SCHEDULE EVERY 1 HOUR DO BEGIN ... END；但事件在 server 层执行，无法跨库、不支持事务回滚，出错难追踪
高频写入场景下，触发器反而拖垮系统
PostgreSQL 或 MySQL 里想用触发器实现“实时刷新”，听着很美，实际极易翻车。
- PostgreSQL 明确禁止在
FOR EACH ROW触发器中执行REFRESH MATERIALIZED VIEW，内核硬限制，报错ERROR: REFRESH MATERIALIZED VIEW cannot be executed from a trigger - 即使走
FOR EACH STATEMENT+ 函数封装，只要基表每秒 DML 超过 20–30 次（比如埋点日志表），每次刷新都触发一次全量重算，CPU 和锁竞争会迅速打满 - 此时应放弃“实时”，改用
pg_cron定时（如每 30 秒一次）或 MySQL 事件（每分钟一次），把刷新节奏收归可控范围
真正容易被忽略的点是：刷新不是越勤越好，而是要和业务容忍延迟对齐。一个报表系统能接受 T+1，你就没必要每分钟刷一次；一个实时看板要求秒级，那触发器+增量更新才是正解——但得先压测验证它不会把数据库拖死。
