PostgreSQL物化视图不支持原生定时刷新，必须依赖外部调度；pg_cron是最主流的数据库内方案，需安装扩展并配置shared_preload_libraries，配合CONCURRENTLY刷新（要求唯一索引且视图非空）；系统crontab调用psql是免扩展替代方案；\watch仅适用于调试，不可用于生产。
PostgreSQL 本身不支持 SQL 层面的原生定时刷新机制，必须依赖外部调度器或客户端工具来周期性执行 REFRESH MATERIALIZED VIEW 命令。
用 pg_cron 插件实现数据库内定时刷新
这是目前最主流、最贴近“数据库原生”的方案，但需管理员权限安装扩展。pg_cron 在 PostgreSQL 后端进程里运行，语法类似系统 cron，任务定义和状态都存于数据库中，便于统一管理。
常见错误现象：执行 SELECT cron.schedule(...) 报错 function "cron.schedule" does not exist —— 说明插件未启用。
- 先确认已安装并加载：
CREATE EXTENSION IF NOT EXISTS pg_cron;，且shared_preload_libraries = 'pg_cron'已写入postgresql.conf并重启服务 - 调度语法示例（每 15 分钟刷新一次）：
SELECT cron.schedule('refresh-daily-stats', '*/15 * * * *', $$REFRESH MATERIALIZED VIEW CONCURRENTLY daily_request_count$$); - 必须用
CONCURRENTLY：否则刷新期间锁表；而该选项要求物化视图上已有UNIQUE索引（如CREATE UNIQUE INDEX ON daily_request_count(day)），否则报错cannot refresh materialized view ... concurrently, because it has no unique index - 首次刷新建议手动执行一次普通
REFRESH MATERIALIZED VIEW daily_request_count，确保视图非空——CONCURRENTLY不允许在空视图上运行
用系统 crontab 调用 psql 执行刷新
无需额外扩展，适合无 superuser 权限或无法修改配置的环境。但要注意连接参数、错误捕获和并发控制。
使用场景：共享主机、云托管 PostgreSQL（如 AWS RDS 默认不开放 pg_cron）、CI/CD 部署脚本集成。
- 典型命令行：
0,15,30,45 * * * * psql -h db.example.com -U myuser -d mydb -c "REFRESH MATERIALIZED VIEW CONCURRENTLY daily_request_count" > /dev/null 2>&1
- 务必加
-c显式指定命令，避免交互式 psql 启动失败；重定向输出防止邮件堆积 - 若刷新耗时较长（> 几分钟），多个 cron 实例可能并发执行，导致冲突或重复刷新——可加文件锁或改用
pg_cron的单实例保障 - 密码需通过
.pgpass文件或PGPASSWORD环境变量提供，切勿写在命令行里（会泄露在ps输出中）
为什么不能用 \watch 或客户端轮询
\watch 是 psql 的前端命令，不是服务器功能。它只是不断新开连接、发命令、等返回，本质是客户端循环，一旦终端断开或网络中断，刷新就停止。
容易踩的坑：
-
\watch 300每 5 分钟刷一次，但每次都是新连接，不复用会话；高频率下易触发连接数限制（max_connections） - 无法做错误重试、日志归档、失败告警；出错时只会打印错误到终端，无人感知
- 不适用于生产环境自动化运维——它是个调试辅助工具，不是调度方案
真正需要稳定自动刷新时，pg_cron 和 crontab + psql 是唯二可靠路径。前者更内聚、易审计；后者更通用、免依赖。但无论哪种，都绕不开一个事实：PostgreSQL 的物化视图刷新永远是全量重算，不是增量同步——这意味着查询越复杂、基表越大，刷新延迟越高，必须提前评估窗口期是否满足业务 SLA。
