物化视图适用于查询开销大且可接受分钟至小时级延迟的场景，如BI报表、次留统计等，通过预计算存储结果提升查询性能至30ms内，并支持权限统一管控与增量刷新，但需严格匹配刷新策略与基表结构。

在查询需反复执行、计算开销颇大，且业务能接受几分钟到几小时数据延迟的情况下，物化视图就该上场了。它绝非“可有可无的优化手段”，而是解决特定性能瓶颈的关键所在——普通视图和索引都无法避免实时重算，而物化视图则将结果存储下来，直接跳过了这一耗时步骤。

查询慢到分钟级，但业务只要“昨天及之前”的数据

典型的应用场景有哪些呢？比如在BI报表中，GMV会按照渠道和日期进行聚合，游戏次留则按注册日来统计。这类SQL操作往往需要扫描包含亿级数据的事实表，同时要JOIN 5张以上的表，并且还包含了SUM、GROUP BY以及窗口函数。每次执行的时间通常在2到5分钟左右。不过，需要注意的是，业务方面只关注历史数据，并不查询实时数据。

• 凌晨用 REFRESH MATERIALIZED VIEW CONCURRENTLY 全量刷新一次，接口查 SELECT * FROM mv_gmv_daily 响应压到 30ms 内
• 字段和分组口径必须稳定——今天按天、明天按小时，物化逻辑就失效
• 上游基表要是只读或 insert-only（如 CDC 同步库），避免 UPDATE/DELETE 导致增量刷新失败

后端服务高频调用重型统计接口，又不想自己维护 Redis 缓存

比如库存汇总、用户活跃宽表，每分钟被调用一次，SQL 包含多层 JOIN 和嵌套子查询，但业务允许 5–10 分钟延迟。

• 比 Redis 更轻量：不用写定时任务、不处理 JSON 序列化/反序列化、还能走数据库索引和事务一致性
• 直接用标准 SQL 查询，开发不用改代码；DBA 通过 last_refresh 字段就能监控数据时效
• 如果基表变更频繁（如每秒上百次 INSERT），全量刷新会拖慢系统，得切到分区增量刷新，或加 grace_period

多个业务方共用一套底层数据，但权限和脱敏规则各不相同

比如不同部门要查同一张用户表，但财务只能看脱敏身份证、运营要拼接组织架构、风控需加行级过滤。

• 把通用过滤 + 脱敏逻辑（如 substr(id_card, 1, 6) || '****' || substr(id_card, -4)）+ 多表 JOIN 封进物化视图，再给各账号授 SELECT 权限
• 权限逻辑统一由 DBA 维护，避免每个应用重复实现，也防止误查敏感字段
• 注意：MATERIALIZED VIEW 不支持 INSERT/DELETE/ALTER，它只是只读快照，别当普通表用

刷新策略没配对，物化视图等于白建

最容易被忽略的是刷新策略和基表变更联动。比如基表加了个字段，物化视图不会自动同步；分区表删了旧分区，对应物化视图分区可能失效，透明改写会退化为直查基表。

• PostgreSQL 中 REFRESH CONCURRENTLY 要求源表有唯一索引，否则报错 cannot refresh concurrently without a unique index
• KingbaseES 必须显式指定 BUILD IMMEDIATE，否则创建后为空，首次查询返回 0 行
• 优化器是否真用了物化视图？金仓默认不会自动重写 SQL，必须满足 WHERE 条件、GROUP BY 字段、聚合函数与定义完全一致（包括别名、函数写法）

《夸克》非常好用的免费AI浏览器

下载APP查看