物化视图适用于查询开销大且可接受分钟至小时级延迟的场景，如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字段、聚合函数与定义完全一致（包括别名、函数写法）
