物化视图参与查询重写必须同时满足四条件：QUERY_REWRITE_ENABLED参数开启、定义含ENABLE QUERY REWRITE子句、结构兼容（如UNION ALL需平铺、列类型一致）、基表有RELY约束且QUERY_REWRITE_INTEGRITY匹配。
物化视图要真正参与查询重写，不是建完就自动生效——必须同时满足参数、定义、结构、权限四方面硬性条件，缺一不可。
QUERY_REWRITE_ENABLED 必须显式开启
Oracle 默认关闭查询重写，哪怕物化视图带 ENABLE QUERY REWRITE，只要这个开关是 FALSE，优化器连候选列表都不会生成。
- 全局启用（需 DBA 权限）：
ALTER SYSTEM SET QUERY_REWRITE_ENABLED = TRUE; - 会话级启用（适合验证）：
ALTER SESSION SET QUERY_REWRITE_ENABLED = TRUE; - 查当前值：
SELECT VALUE FROM V$PARAMETER WHERE NAME = 'query_rewrite_enabled';—— 注意返回的是字符串'TRUE'或'FALSE'，不是数字 - 常见坑：应用连接池未执行
ALTER SESSION，导致生产环境实际仍是默认FALSE
物化视图定义必须含 ENABLE QUERY REWRITE 子句
建 MV 时漏掉 ENABLE QUERY REWRITE，它就只是个普通表，不会进入重写决策流程；/*+ REWRITE */ hint 也救不回来。
- 正确写法：
CREATE MATERIALIZED VIEW mv_sales REFRESH FAST ON COMMIT ENABLE QUERY REWRITE AS SELECT ...; - 错误写法：
CREATE MATERIALIZED VIEW mv_sales REFRESH COMPLETE ON DEMAND AS SELECT ...;（缺子句 + 刷新方式也不支持重写） - 已有 MV 漏了该子句？不能
ALTER补，只能DROP后重建 - 注意兼容性：
ENABLE QUERY REWRITE要求基表有主键或已启用ROWID，否则建 MV 会报ORA-30353
UNION ALL 视图无法直接被重写，逻辑必须下沉到 MV 定义中
含 UNION ALL 的视图本身不会被重写器识别——优化器要求“单源语义可推导”，而 UNION ALL 是多源并集，无法安全映射刷新日志与键约束。
- 不能这样建：
CREATE MATERIALIZED VIEW mv_hist_curr ENABLE QUERY REWRITE AS SELECT * FROM v_hist_union_all;（v_hist_union_all是含UNION ALL的视图） - 必须这样写：
CREATE MATERIALIZED VIEW mv_hist_curr ENABLE QUERY REWRITE AS SELECT col1, col2 FROM t_hist UNION ALL SELECT col1, col2 FROM t_curr;（逻辑平铺进 MV 定义） - 关键细节：列名必须显式写出，不能用
*；对应列数据类型要完全一致（如都为VARCHAR2(50)）；NULL 性不一致时需用CAST(... AS ...)或TO_NUMBER(NULL)统一声明 - 如果某列在
t_hist中是NOT NULL、在t_curr中是NULL，MV 中该列最终为NULL，应用层需接受此语义
QUERY_REWRITE_INTEGRITY 设置影响重写可用性
该参数控制优化器对物化视图数据新鲜度和约束可信度的要求，默认 ENFORCED 最严格，也是最容易静默失败的点。
-
ENFORCED：要求基表有RELY ENABLE NOVALIDATE PRIMARY KEY等约束，且 MV 必须是FRESH状态，否则直接跳过重写 -
TRUSTED：允许基表约束为NOVALIDATE，但必须标RELY；MV 可以是FRESH或STALE（取决于刷新策略） -
STALE_TOLERATED：即使 MV 是STALE状态也允许重写（风险自担） - 验证是否命中重写：
EXPLAIN PLAN FOR ...后查PLAN_TABLE_OUTPUT，看OBJECT_NAME是否为 MV 名；也可用DBMS_MVIEW.EXPLAIN_REWRITE查具体失败原因
最常被忽略的是 QUERY_REWRITE_INTEGRITY 和基表约束的配合——尤其在迁移或新建环境时，RELY 约束容易遗漏，导致明明 MV 状态正常、参数全开，却始终不重写。
