物化视图是预计算并持久化查询结果的物理表，通过跳过复杂计算提升读性能，但需权衡刷新策略以保障与基表的一致性。
物化视图本质是把查询结果“存下来”的物理表，它通过预计算提升查询性能，但需额外处理数据更新时的一致性问题。
预计算：把慢查询变快查
普通视图每次查询都重跑SQL，而物化视图在创建或刷新时，把SELECT结果实际写入磁盘（一张真实表）。后续查询直接读这张表，跳过复杂JOIN、聚合、子查询等耗时操作。
- 适合查询模式稳定、计算开销大、读远多于写的场景（如报表统计、BI看板）
- 可建索引、分区、压缩，进一步优化读取效率
- 部分数据库（如Oracle、PostgreSQL with pg_matview、Doris、ClickHouse）原生支持；MySQL需手动模拟（用普通表+定时任务）
一致性维护：数据变了，物化视图怎么跟上？
底层基表更新后，物化视图不会自动同步——这是它和普通视图最根本的区别。一致性靠“刷新策略”保障，常见方式有：
- 完全刷新（Full Refresh）：丢弃旧数据，重新执行定义SQL生成全量新结果。简单可靠，但锁表时间长、资源消耗大，适合夜间批量更新
- 增量刷新（Incremental Refresh）：只捕获基表变化（如通过CDC日志、时间戳字段、变更标记表），仅更新受影响的行。要求物化视图逻辑可增量表达（例如SUM、COUNT需对应变更抵消），实现较复杂但实时性好
- ON COMMIT / ON STATEMENT：事务提交时或语句执行后自动触发刷新（Oracle支持），强一致性但影响写入性能
关键权衡点：性能 vs. 延迟 vs. 维护成本
选哪种方案不只看技术是否支持，更要看业务容忍度：
- 报表类场景接受分钟级延迟 → 定时全量刷新（每小时/每天）足够，运维简单
- 实时看板要求秒级更新 → 需增量刷新 + 变更日志捕获，架构复杂但值得
- 基表频繁小更新、物化视图逻辑含不可增量函数（如ROW_NUMBER()、某些窗口函数）→ 全量刷新仍是务实选择
- 注意物化视图本身占用存储、刷新过程消耗CPU/IO，需监控其资源水位
不复杂但容易忽略：物化视图不是银弹，它用空间换时间，用延迟换吞吐。设计前先问清楚——这个查询真慢吗？慢在哪？数据多久才允许“旧”一次？
