先确认数据库是否真正支持物化视图：PostgreSQL 9.3+ 原生支持，MySQL 完全不支持，SQL Server 称“索引视图”且需 WITH SCHEMABINDING 和唯一聚集索引，Oracle 用 MATERIALIZED VIEW + REFRESH 子句；执行 pg_class 查询或 USER_MVIEWS 才能验证对象类型。
物化视图刷新不生效？先确认数据库是否真正支持“物化视图”
很多用户遇到“刷新没用”，其实是误把普通视图当成了物化视图。PostgreSQL、SQL Server、Oracle 等对物化视图的支持差异很大：MATERIALIZED VIEW 是 PostgreSQL 9.3+ 的关键词，而 MySQL 完全不原生支持；SQL Server 叫“索引视图”，且必须用 WITH SCHEMABINDING 创建并加唯一聚集索引；Oracle 则用 MATERIALIZED VIEW + REFRESH 子句。执行 SELECT * FROM pg_class WHERE relkind = 'm'（PostgreSQL）或查 USER_MVIEWS（Oracle）才能确认对象类型——不是所有带“view”的名字都是物化视图。
PostgreSQL 中强制刷新物化视图：用 REFRESH MATERIALIZED VIEW 而非 SELECT
PostgreSQL 不会自动同步底层表变更，必须显式刷新。默认是全量重算，阻塞读写：
REFRESH MATERIALIZED VIEW my_mv;
若想避免锁表，可加 CONCURRENTLY（但要求物化视图有唯一索引，且不能在事务块中使用）：
REFRESH MATERIALIZED VIEW CONCURRENTLY my_mv;
- 没有唯一索引时加
CONCURRENTLY会报错：ERROR: cannot refresh materialized view "my_mv" concurrently -
CONCURRENTLY模式下，刷新期间仍可读取旧数据，但新查询会看到逐步更新的结果，不是原子切换 - 不要在函数或触发器里频繁调用
REFRESH，I/O 和 CPU 开销大，容易拖慢主业务
Oracle 中刷新策略选错会导致数据陈旧或失败
Oracle 的 REFRESH 方式直接影响时效性和权限要求：
-
REFRESH COMPLETE：全量重建，最安全，但慢；需对基表有SELECT权限 -
REFRESH FAST：只应用物化视图日志里的变更，快但限制多——基表必须建日志（CREATE MATERIALIZED VIEW LOG ON t），且语句需满足“可快速刷新”条件（如不能含ROWNUM、聚合无DISTINCT） -
REFRESH FORCE：先试FAST，失败则退到COMPLETE；适合不确定环境，但无法预估耗时
常见错误是直接运行 EXEC DBMS_MVIEW.REFRESH('MY_MV') 却没指定 method 参数，默认为 FORCE，但日志缺失时会静默降级，表面成功实则数据未更新。
SQL Server 索引视图不“刷新”，靠查询计划和统计信息隐式生效
SQL Server 没有 REFRESH 命令。它的“索引视图”本质是带唯一聚集索引的视图，数据随基表 DML 实时维护——但前提是查询必须满足“引用该视图且启用 NOEXPAND 提示”，否则优化器可能绕过索引视图直接查基表：
SELECT * FROM MyIndexedView WITH (NOEXPAND);
如果没加 NOEXPAND，即使视图已建好索引，查询也可能返回“最新数据”，但走的是基表扫描，不是物化结果。另外，统计信息过期会导致优化器忽略索引视图，需定期更新：UPDATE STATISTICS MyIndexedView。
真正的麻烦在于：你以为它在“物化”，其实它只是个带索引的 SQL 表达式——没有独立存储快照，也没有刷新概念。这点和 PostgreSQL/Oracle 有本质区别。
