物化视图查询重写失败的主因是配置与语义未对齐：需确认QUERY_REWRITE_ENABLED参数为TRUE/FORCE、MV启用ENABLE QUERY REWRITE、调用DBMS_MVIEW.EXPLAIN_REWRITE验证重写可行性，并确保SQL与MV定义字段、过滤、分组、连接完全匹配，且权限、统计信息、MV状态均合规。
物化视图建了、enable query rewrite也加了，但查询还是走基表——这不是 bug，是配置或语义没对齐。
为什么 EXPLAIN PLAN 里看不到 MATERIALIZED VIEW REWRITE
这是最典型的误判点：很多人用 EXPLAIN PLAN FOR SELECT ... + DBMS_XPLAN.DISPLAY 看执行计划，发现访问的仍是基表，就以为重写失败。但这个视图只显示优化器“最终选了谁”，不告诉你“它有没有尝试重写”。
-
EXPLAIN PLAN不会显示“被拒绝的物化视图”，哪怕有 10 个 MV 都因语义不匹配被跳过，它也只安静地走基表 - 真正能确认是否触发重写的唯一方式是调用
DBMS_MVIEW.EXPLAIN_REWRITE - 必须传入原始 SQL 字符串（不能带绑定变量），且用户要有
EXECUTE权限 onDBMS_MVIEW
示例：
EXEC DBMS_MVIEW.EXPLAIN_REWRITE( 'SELECT region, SUM(amount) FROM sales WHERE order_date > SYSDATE-7 GROUP BY region', 'MV_SALES_SUM' );
然后查 REWRITE_TABLE（需先运行 UTLXRWY.SQL 建表）——输出里出现 REWRITE_CAN_BE_USED = 'Y' 才算通过第一关。
QUERY_REWRITE_ENABLED 和对象级开关必须同时为真
Oracle 默认关闭全局重写开关，哪怕物化视图上写了 ENABLE QUERY REWRITE，也没用。
- 检查全局参数：
SELECT VALUE FROM V$PARAMETER WHERE NAME = 'query_rewrite_enabled';—— 必须是TRUE或FORCE（FORCE会忽略 MV 上的DISABLE设置） - 检查物化视图本身是否启用：
SELECT QUERY_REWRITE_ENABLED FROM USER_MVIEWS WHERE MVIEW_NAME = 'MV_SALES_SUM';—— 值应为ENABLED - 如果已存在 MV 但没启用重写，不能 ALTER SESSION 修改，只能：
ALTER MATERIALIZED VIEW mv_sales_sum ENABLE QUERY REWRITE;
注意：QUERY_REWRITE_INTEGRITY 默认是 ENFORCED，要求 MV 数据与基表严格一致；若 MV 刷新滞后（比如 ON DEMAND 且还没手动刷新），重写会被直接禁用——这时设为 TRUSTED 可绕过校验，但你要自己担数据一致性风险。
SQL 查询和物化视图定义之间存在“隐形断层”
优化器不会做“推导”，只做“匹配”。哪怕你直觉上觉得“这个查询肯定能用 MV”，只要字段、过滤、分组、连接逻辑有一处对不上，就直接放弃。
-
SELECT列必须能从 MV 中直接取到或无损计算：MV 有SUM(sales)，但 SQL 查AVG(sales)→ 不匹配 -
WHERE条件列必须全部出现在 MV 的SELECT或GROUP BY中：MV 没包含order_date，SQL 却加了时间范围 → 不匹配 - 多表 JOIN 查询，MV 必须包含所有关联表 + 关联条件：单表 MV
SELECT region, SUM(amount) FROM sales...无法支撑sales JOIN customers ON ...的查询 - 聚合粒度必须覆盖：MV 是按
region分组，SQL 却要按region, product_type分组 → 不匹配（除非 MV 包含更细粒度数据）
一个简单验证法：把原 SQL 的 FROM 和 WHERE 部分，逐字对照 MV 的 AS SELECT ... 子句——能完全套进去，才可能重写成功。
权限和统计信息这些“静默门槛”容易被跳过
没有报错，但重写就是不生效，大概率卡在这两个地方。
- 用户必须有
QUERY REWRITE系统权限，或对当前 MV 有对象级QUERY REWRITE权限（不是SELECT权限！） - 基表和 MV 都要收集最新统计信息：
DBMS_STATS.GATHER_TABLE_STATS对基表，DBMS_STATS.GATHER_MVIEW_STATS对 MV（19c 支持后者）；否则优化器成本估算失真，可能认为走 MV 更贵 - MV 状态要是
VALID：SELECT STALENESS FROM USER_MVIEWS WHERE MVIEW_NAME = 'MV_SALES_SUM';—— 如果是STALE，且QUERY_REWRITE_INTEGRITY = ENFORCED，重写自动失效
复杂点在于：这些条件之间是“与”关系，缺一不可；而错误表现都是静默回退到基表，没有任何 warning 或 error 提示。所以排查时别只盯一个点，得按顺序过一遍——特别是 DBMS_MVIEW.EXPLAIN_REWRITE 的输出，它会明确告诉你卡在哪一步，比如 QSM-01105: query rewrite not possible due to missing join predicate 这种提示，比猜强十倍。
