物化视图能替代Cube聚合，但必须启用QUERY REWRITE、使用GROUPING()函数、且满足完整性约束；普通视图无法规避实时计算与NULL语义混淆问题。
物化视图能直接替代Cube聚合逻辑，但必须配合QUERY REWRITE和显式GROUPING SETS，否则查询根本不会命中MV，白建。
为什么普通视图+GROUP BY无法替代物化视图做Cube聚合
普通视图只是SQL模板，每次查询都重跑整个聚合，遇到多维组合（比如GROUP BY CUBE(time, region, product)）时，Oracle仍需实时扫描基表、生成所有分组、处理NULL语义——性能随维度数指数级恶化。而物化视图把结果固化成物理表，查询直接读取已聚合数据，跳过所有计算环节。
常见错误现象包括：报表导出耗时从2秒涨到18秒、BI工具反复执行同一SELECT ... GROUP BY CUBE(...)、AWR里sql_id对应SQL的elapsed_time长期居高不下。
- 普通视图不存储数据，无法规避重复JOIN和聚合开销
- CUBE生成的汇总行中维度列为NULL，但真实数据也可能为NULL，下游无法区分，导致小计/合计逻辑错乱
- 没有物化视图日志时，快速刷新不可用；而全量刷新又会锁表，影响业务
创建支持Cube聚合的物化视图必须满足的三个硬条件
Oracle 19c允许在物化视图定义中直接写GROUPING SETS或CUBE，但要让查询真正重写到它上面，缺一不可：
- 物化视图必须启用查询重写：
ENABLE QUERY REWRITE，且用户有QUERY REWRITE权限 - 数据库参数
QUERY_REWRITE_ENABLED = TRUE，且QUERY_REWRITE_INTEGRITY不能设为ENFORCED（否则要求基表有RELY ENABLE NOVALIDATE PRIMARY KEY，否则静默失败） - 物化视图定义中必须用
GROUPING()函数包裹各维度列，例如GROUPING(time) AS time_grp，否则无法区分汇总NULL与真实NULL
示例关键片段：
CREATE MATERIALIZED VIEW mv_sales_cube BUILD IMMEDIATE REFRESH FAST ON COMMIT ENABLE QUERY REWRITE AS SELECT time, region, product, GROUPING(time) AS time_grp, GROUPING(region) AS region_grp, GROUPING(product) AS product_grp, SUM(amount) AS total_amt FROM sales_fact GROUP BY GROUPING SETS ( (time, region, product), (time, region), (time, product), (region, product), (time), (region), (product), () );
查询重写不生效？先查DBMS_MVIEW.EXPLAIN_REWRITE
即使物化视图建好了，业务SQL也未必走它。最可靠的方式是用Oracle内置诊断工具验证：
- 执行
DBMS_MVIEW.EXPLAIN_REWRITE('SELECT ...', 'mv_sales_cube')，查REWRITE_TABLE输出 - 若返回
UNREWRITTEN，常见原因包括：源SQL用了UNION ALL、物化视图未ENABLE QUERY REWRITE、基表缺少统计信息（DBMS_STATS.GATHER_TABLE_STATS没跑） - 注意：自动索引对物化视图本身无效，它只优化基表扫描；别指望靠
AUTOMATIC INDEXING救活重写失败的查询
典型干扰点：EXPLAIN PLAN显示走基表全扫，但REWRITE_TABLE里却写着TEXT字段为QUERY NOT REWRITTEN DUE TO MISSING CONSTRAINT——这说明问题不在索引，而在约束缺失。
增量更新场景下，FAST REFRESH比COMPLETE更危险
如果你的Cube需要按天/小时追加新数据，千万别默认用REFRESH FAST。它依赖物化视图日志，而日志本身会拖慢基表DML性能，尤其当sales_fact每秒写入上千行时，日志维护开销可能超过查询收益。
- 快速刷新要求基表必须有物化视图日志，且日志需包含所有GROUP BY列和聚合列（如
WITH SEQUENCE, ROWID, (time, region, product, amount)） - 日志表本身会成为热点，
INSERT INTO mlog$_sales_fact可能在AWR里排进Top 5等待事件 - 更稳妥的做法是：用
REFRESH COMPLETE ON DEMAND+ 分区交换（如按time分区），每天凌晨用ALTER TABLE sales_fact EXCHANGE PARTITION把新分区数据“搬”进物化视图，避免全表锁
复杂点在于：GROUPING SETS产生的结果行数远超原始事实行数，物化视图段大小容易预估不足，建议建表前用DBMS_SPACE.CREATE_TABLE_COST估算空间，否则刷新时可能报ORA-01652。
