物化视图不能替代GROUP BY查询，需显式刷新且依赖日志配置；多表JOIN不支持ON COMMIT刷新；FAST刷新须建匹配的日志；LEFT JOIN和SCD Type 2易致刷新变慢；查询重写需启用并验证执行计划。
不能直接用物化视图替代 GROUP BY 查询，它不是自动缓存，而是需要你明确控制刷新时机和方式的物理表。
物化视图必须显式刷新才能反映新数据
很多人以为建完 CREATE MATERIALIZED VIEW mv_sales_sum 就能自动同步，结果 SELECT * FROM mv_sales_sum 还是旧值，而 INSERT INTO fact_sales 已执行多分钟。这是因为 Oracle 默认刷新策略是 ON DEMAND（需手动触发），不是实时生效。
- 想提交即更新，得用
REFRESH FAST ON COMMIT，但仅限单表、且基表必须有MATERIALIZED VIEW LOG - 跨多表 JOIN 的物化视图不支持
ON COMMIT，只能靠定时或手动刷新 - 刷新命令是
DBMS_MVIEW.REFRESH('mv_sales_sum')，不是REFRESH MATERIALIZED VIEW（那是 PostgreSQL 语法）
FAST 刷新不是开箱即用，依赖物化视图日志配置
启用 FAST 刷新前，必须在每个基表上创建日志，否则 REFRESH FAST 会退化成 COMPLETE，且不报错——只悄悄变慢。
- 日志创建语句必须包含所有被 SELECT 的列：例如
CREATE MATERIALIZED VIEW LOG ON fact_sales WITH ROWID, SEQUENCE(sales_amt, region_id) INCLUDING NEW VALUES - 如果物化视图用了
JOIN，所有参与表都要建日志，且字段列表要对齐 -
WITH PRIMARY KEY比WITH ROWID更安全，但要求基表有主键；没主键时用ROWID，但表结构变更（如重建）会导致日志失效
多表 JOIN 场景下，维度表更新极易导致刷新变慢
比如物化视图定义里写了 LEFT JOIN dim_promotion，而该维度表每天全量覆盖（TRUNCATE + INSERT），哪怕只改了一行促销信息，整个物化视图也得重算——Oracle 无法判断哪些事实行真正受影响。
- 优先用
INNER JOIN，避免LEFT/RIGHT JOIN引入不确定性 - 维度表尽量用 SCD Type 1（覆盖更新），别用 Type 2（新增版本行）；若必须用 Type 2，物化视图 SQL 中得显式加
WHERE valid_from <= SYSDATE AND valid_to > SYSDATE - 更稳妥的做法是宽表化：把
region_name、product_category等字段冗余进事实表，然后基于单表建物化视图
查询是否真走物化视图，得看执行计划里的实际扫描源
光看 EXPLAIN PLAN 输出里有没有 mv_sales_sum 名字没用，得确认优化器是否真把它当数据源用了。Oracle 的查询重写（QUERY REWRITE）可能被禁用，或因统计信息过期、一致性级别太严而跳过。
- 启用重写：建视图时加
ENABLE QUERY REWRITE，并确保参数QUERY_REWRITE_ENABLED = TRUE - 验证是否命中：运行
EXPLAIN PLAN FOR SELECT sum(sales_amt) FROM fact_sales JOIN dim_region USING(region_id);，再查SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY)，看Plan列是否出现TABLE ACCESS FULLonmv_sales_sum - 如果没命中，检查
QUERY_REWRITE_INTEGRITY设置：设为STALE_TOLERATED可容忍少量过期数据，提高重写成功率
最常被忽略的是：物化视图本身是一张物理表，它的统计信息也要定期收集（DBMS_STATS.GATHER_TABLE_STATS），否则优化器可能误判成本，宁愿扫大基表也不走物化视图。
