SQL 物化视图适合哪些场景？

物化视图适用于查询复杂、读多写少、实时性要求不高但响应速度敏感的场景，如T+1报表、只读归档分析、高频延迟容忍统计接口及权限脱敏封装等。

物化视图适合那些查询复杂、读多写少、对实时性要求不高但对响应速度敏感的场景。它不是万能缓存，关键在于用空间换时间，同时接受一定延迟。

报表与 BI 类固定聚合

日/月/年报类统计 SQL 需扫描几亿行、关联十几张表、含窗口函数，单次执行耗时 3–5 分钟，但业务只关心“昨天及之前”的数据。这时可在凌晨用 REFRESH CONCURRENTLY 全量刷新一次，接口查询直接落在物化视图上，响应压到 30 毫秒以内。

• 字段和分组口径稳定（如电商 GMV 按渠道+日期、游戏次留按注册日期）
• 允许 T+1 数据新鲜度，不需秒级更新
• 避免每次报表请求都触发重型计算

上游数据只读或 insert-only

源库是历史归档库、CDC 同步库或应用明确保证不执行 UPDATE/DELETE 的只读库。这种情况下，物化视图无需处理增量逻辑，可放心采用全量刷新策略，省去建物化视图日志、维护 FAST 刷新依赖等复杂操作。

• 数据变更模式简单：只有新增，无修改或删除
• 刷新成本可控，且结果绝对一致
• 特别适合归档分析、合规审计类场景

高频调用的重型统计接口

后端服务频繁调用一条代价高昂的统计 SQL（例如实时库存汇总、用户活跃度宽表），但业务能容忍 5–1

0 分钟延迟。用物化视图替代 Redis 手动序列化更轻量——不用自己写定时任务同步、不用处理 JSON 序列化/反序列化、还能走数据库优化器和索引。

• 直接用标准 SQL 查询，开发维护成本低
• 支持原生事务一致性（如 PostgreSQL 的 CONCURRENTLY）
• 比应用层缓存更容易监控数据时效性（查 last_refresh 字段）

权限与脱敏封装中间层

当多个业务方需访问同一套底层数据，但各自有不同行级安全规则、字段脱敏要求或嵌套权限逻辑时，可把通用过滤 + 脱敏 + 多层 JOIN 封装进物化视图，再给各账号授予该 MV 的 SELECT 权限。避免每个应用重复实现相同权限逻辑。

• 权限控制下沉，统一由 DBA 维护
• 查询语句简洁，业务方只需 SELECT * FROM mv_sales_cn
• 配合视图重写（如 Oracle）或查询路由，对上层完全透明