PostgreSQL 9.4+ 原生支持 REFRESH MATERIALIZED VIEW，而 MySQL、SQL Server、Oracle 12c 之前不提供物化视图；Oracle 12c+ 使用 DBMS_MVIEW.REFRESH，SQL Server 的“索引视图”不可手动刷新。
物化视图不支持标准 SQL 的 REFRESH MATERIALIZED VIEW？先确认数据库类型
PostgreSQL 9.4+ 原生支持 REFRESH MATERIALIZED VIEW，但 MySQL、SQL Server、Oracle（12c 之前）根本不提供物化视图；Oracle 12c+ 用的是 DBMS_MVIEW.REFRESH，SQL Server 叫“索引视图”且不能手动刷新——它随基表自动更新。所以第一步不是写脚本，而是查清你用的到底是不是真·物化视图。
常见误判点：
- 把普通视图 + 定时导出表当作物化视图（比如每天
INSERT INTO summary_table SELECT ...） - 在 MySQL 里搜
CREATE MATERIALIZED VIEW，结果语法报错 - 用 PostgreSQL 却连到旧版本（REFRESH 命令不存在
PostgreSQL：用 psql + cron 实现最小可行定时刷新
核心逻辑是把刷新命令塞进 shell 脚本，再用系统级定时任务触发。不依赖扩展或外部调度器，上线快、排查直接。
实操建议：
- 写一个
refresh_mv.sh，开头加#!/bin/bash，内容为：psql -U myuser -d mydb -c "REFRESH MATERIALIZED VIEW CONCURRENTLY sales_summary_mv;"
-
CONCURRENTLY必须加——否则刷新期间视图不可读，线上查询会阻塞 - 确保该物化视图已建唯一索引（
CONCURRENTLY强制要求），否则报错：ERROR: cannot refresh materialized view "sales_summary_mv" concurrently - 给脚本加执行权限：
chmod +x refresh_mv.sh，再用crontab -e添加：0 2 * * * /path/to/refresh_mv.sh >> /var/log/mv_refresh.log 2>&1
没有原生物化视图？用“伪物化”替代方案保底线
MySQL 或旧版 SQL Server 用户，得自己模拟物化行为：建一张物理表，定期重算并原子替换。关键不在“怎么算”，而在“怎么换”不出错。
安全替换三步法：
- 新数据写入临时表：
CREATE TABLE sales_summary_new AS SELECT ... - 原子重命名（避免中间态空表）：
RENAME TABLE sales_summary TO sales_summary_old, sales_summary_new TO sales_summary; - 删旧表：
DROP TABLE sales_summary_old;（别漏这步，否则磁盘悄悄涨） - 注意：MySQL 的
RENAME TABLE是原子操作，但整个流程没事务包裹，失败时需人工干预
刷新脚本里最容易被忽略的权限和连接问题
脚本在 cron 下跑失败，90% 不是 SQL 写错，而是环境差异导致的权限或连接问题。
典型现象和对策：
- cron 执行时报
psql: FATAL: database "mydb" does not exist→ 没加载用户环境变量，psql找不到PGDATABASE，必须显式指定-d mydb - 报
Peer authentication failed for user "myuser"→ cron 默认用root或系统用户跑，而 pg_hba.conf 只允许本地peer认证当前登录用户，解决方案是改用md5认证 +.pgpass文件，或统一用sudo -u postgres psql - 脚本里用
date或awk处理时间戳？cron 默认$PATH极简，务必写绝对路径，比如/usr/bin/date
复杂点在于：数据库密码、连接参数、错误重试、日志轮转这些事，都得自己补全。原生支持的数据库省心，不支持的就得一层层填坑。
