物化视图适用于查询重、写少、可容忍延迟的场景，如报表BI固定聚合、高频重型统计接口、权限与脱敏封装中间层，需配合稳定字段口径、只读基表及合理刷新策略。
适合用物化视图的场景，核心就一条：查询重、写少、能容忍延迟。 它不是缓存替代品，也不是实时同步方案，而是用空间换时间的确定性优化手段——只要业务能接受几分钟到几小时的数据新鲜度，且查询本身开销大、调用频次高，就值得考虑。
报表与 BI 类固定聚合
比如电商 GMV 按渠道+日期统计、游戏次留按注册日期计算，这类 SQL 通常扫描亿级数据、关联 5 张以上表、含 SUM + GROUP BY + 窗口函数，单次执行耗时 2–5 分钟。但业务只看“昨天及之前”的数据。
- 凌晨用
REFRESH CONCURRENTLY全量刷新一次，接口查SELECT * FROM mv_gmv_daily响应压到 30ms 内 - 字段和分组口径必须稳定，不能今天按天、明天按小时，否则物化逻辑失效
- 上游要是只读或 insert-only（如 CDC 同步库），避免
UPDATE/DELETE导致增量刷新逻辑崩坏
高频调用的重型统计接口
后端服务每分钟调用一次库存汇总或用户活跃宽表，SQL 包含多层 JOIN 和嵌套子查询，但业务允许 5–10 分钟延迟。
- 比 Redis 手动序列化更轻量：不用写定时任务、不处理 JSON 序列化/反序列化、还能走数据库索引和事务一致性
- 直接用标准 SQL 查询，开发不用改代码，DBA 通过
last_refresh字段就能监控数据时效 - 注意：如果基表变更频繁（如每秒上百次
INSERT），全量刷新会拖慢系统，得切到分区增量刷新或加grace_period
权限与脱敏封装中间层
多个业务方共用一套底层数据，但各自有不同行级权限、字段脱敏规则（如隐藏身份证后四位）、或需拼接组织架构表。
- 把通用过滤 + 脱敏 + 多表
JOIN封进物化视图，再给各账号授SELECT权限，权限逻辑统一由 DBA 维护 - 避免每个应用重复实现相同逻辑，也防止误查敏感字段
- 注意：物化视图不支持
INSERT/DELETE/ALTER，它只是只读快照，别当普通表用
真正容易被忽略的是刷新策略和基表变更联动。比如基表加了个字段，物化视图不会自动同步；分区表删了旧分区，对应物化视图分区会失效，透明改写可能退化为直查基表——这些都得靠监控和定期巡检来兜底。
