物化视图是解决数据仓库中高频复杂JOIN与聚合性能瓶颈的刚性方案，因其将预计算结果物理存储，避免重复执行耗时操作；KingbaseES当前仅支持全量刷新（REFRESH COMPLETE），需显式指定BUILD IMMEDIATE、配合CONCURRENTLY刷新及启用enable_materialized_views参数才能生效。
物化视图在数据仓库建模中不是“锦上添花”，而是解决核心性能瓶颈的刚性需求——当事实表与维度表频繁 JOIN、聚合计算耗时超过秒级，且业务接受分钟级/小时级数据延迟时，MATERIALIZED VIEW 就是唯一能绕过实时计算代价的物理层方案。
为什么不能只用普通视图或加索引？
普通视图（CREATE VIEW）每次查询都重跑整个 SQL，面对千万级事实表 + 多维 JOIN + GROUP BY + WINDOW FUNCTION，响应时间从秒变分钟；而单纯给基表加索引对跨表聚合无效——索引加速的是单表过滤和连接，不加速 SUM/COUNT/DISTINCT 等聚合运算本身。物化视图把“聚合结果”直接存成物理表，相当于把 SELECT SUM(sales_amt) FROM fact_sales JOIN dim_time ... GROUP BY month 的输出固化下来，后续查月度汇总就是纯主键扫描。
金仓 KingbaseES Oracle 兼容模式下怎么创建才真正生效？
语法看似和 Oracle 一致，但实际生效依赖三个隐性条件：
- 必须显式指定
BUILD IMMEDIATE（默认是DEFERRED），否则创建后为空，首次查询返回 0 行； - 若想支持并发刷新（
REFRESH CONCURRENTLY），源表必须有唯一索引（通常是主键），否则会报错ERROR: cannot refresh concurrently without a unique index； - 物化视图名不能和已有表/视图同名，且不能带 schema 前缀（如
public.mv_monthly_sales会失败），直接用mv_monthly_sales即可。
刷新策略选 COMPLETE 还是等 FAST？
当前金仓 KingbaseES（截至 2026 年 6 月）仍不支持 FAST REFRESH，所有刷新都是全量重建。这意味着：
-
REFRESH COMPLETE是唯一选项，刷新耗时 = 原始查询执行时间 × 2（一次读原始数据，一次写新数据）； - 不要在高峰期执行
REFRESH MATERIALIZED VIEW mv_xxx，否则会锁住物化视图对象，阻塞下游报表查询； - 务必配合
CONCURRENTLY使用（如REFRESH MATERIALIZED VIEW CONCURRENTLY mv_xxx），它允许刷新期间继续读取旧版本数据，避免查询中断。
最容易被忽略的陷阱：优化器是否真用了物化视图？
创建成功 ≠ 查询自动命中。金仓默认不会自动重写 SQL 去走物化视图，必须满足两个硬性条件：
- 查询语句的 WHERE 条件、GROUP BY 字段、聚合函数必须与物化视图定义**完全一致**（包括别名、函数嵌套层级）；
- 需手动开启物化视图重写开关：
SET enable_materialized_views = on;（该参数默认为off）； - 执行
EXPLAIN查看执行计划，确认出现Materialize节点或扫描目标为mv_xxx表名，而非原始基表。
没验证执行计划就上线，等于白建。
