最关键字段是MSGNO、MSGTXT和CAPABILITY_NAME；其中CAPABILITY_NAME='REWRITE'的POSSIBLE值为'Y'或'N'直接判定是否可重写，MSGTXT提供具体失败原因如UNION ALL、分区键未使用或表达式不支持等。
DBMS_MVIEW.EXPLAIN_MVIEW 输出里哪些字段最关键
它不直接告诉你“为什么没重写”，而是把 Oracle 内部的校验逻辑逐项摊开。关键就三列：MSGNO、MSGTXT、CAPABILITY_NAME。其中 CAPABILITY_NAME = 'REWRITE' 对应的 POSSIBLE 值是最终判决——'Y' 表示可重写，'N' 就是明确拒绝。
MSGTXT 是人话诊断，比如：
-
"query contains a UNION ALL operator"—— 物化视图定义或查询中用了UNION ALL，重写器直接放弃 -
"partition key not used in query"—— 查询没过滤物化视图的分区键列，或用了函数包装（如TRUNC(dt)） -
"expression not supported for rewrite"—— 查询中对重写候选列做了类型转换、NVL、DECODE等非确定性操作
为什么不能只看 EXPLAIN_PLAN 就下结论
EXPLAIN PLAN FOR 显示走基表，不代表重写失败；它只反映优化器当前的成本估算路径。真正决定是否重写的，是 DBMS_MVIEW.EXPLAIN_REWRITE 的语义校验结果。
常见误判场景：
- 物化视图状态为
STALE，但QUERY_REWRITE_INTEGRITY = STALE_TOLERATED未启用 →EXPLAIN_REWRITE返回no match，而EXPLAIN PLAN还在基表上算成本 - 查询中列名大小写不一致（尤其双引号定义的列），
EXPLAIN_REWRITE认为语义不等价，直接跳过；EXPLAIN PLAN却可能因隐式转换“碰巧”走 MV - 物化视图含聚合，但查询取明细 →
EXPLAIN_REWRITE明确返回QSMQT_UNREWRITE，而EXPLAIN PLAN可能显示访问 MV 本身（只是没做谓词下推）
如何用 EXPLAIN_MVIEW 定位 UNION ALL 或函数包装问题
当查询或物化视图定义中含 UNION ALL，EXPLAIN_MVIEW 通常不会报错，而是让 REWRITE 能力的 POSSIBLE 值为 'N'，MSGTXT 里带一句模糊提示，比如 "complex SQL" 或空值。这时候得人工交叉验证：
- 检查物化视图 DDL：运行
SELECT TEXT FROM DBA_VIEWS WHERE VIEW_NAME = 'YOUR_MV_NAME'，确认是否含UNION ALL - 检查查询文本：把完整 SQL 粘进
DBMS_MVIEW.EXPLAIN_REWRITE('your sql', 'MV_NAME')，若返回UNREWRITTEN且MSGTXT含"operator not supported"，基本锁定 - 对分区键列，查
USER_TAB_PARTITIONS确认物理分区列名，再比对查询中 WHERE 条件是否严格匹配该列名、无任何函数包裹
执行前必须建好 MV_CAPABILITIES_TABLE
DBMS_MVIEW.EXPLAIN_MVIEW 默认输出到 MV_CAPABILITIES_TABLE，这个表不是 Oracle 自带的，得手动建。脚本位置在 $ORACLE_HOME/rdbms/admin/utlxmv.sql，必须以有 CREATE TABLE 权限的用户运行一次：
SQL> @?/rdbms/admin/utlxmv.sql
漏建会导致过程静默失败或报 ORA-00942: table or view does not exist。建完后每次调用都需指定 STATEMENT_ID，否则新结果会覆盖旧记录，容易误判。
真正难的不是跑出结果，而是读懂 MSGTXT 里那句看似笼统的提示背后对应的 Oracle 内部限制——比如 "expression not supported" 可能指向类型转换，也可能指向 NLS 设置差异，得结合查询实际执行环境再挖一层。
