DBMS_MVIEW.EXPLAIN_REWRITE 能精准定位物化视图重写失败的具体原因，需结合 QUERY_REWRITE_ENABLED 会话级生效状态、QUERY_REWRITE_INTEGRITY 约束验证要求、MV 的 STALENESS 状态与统计信息、以及基表物化视图日志完整性综合排查。
EXPLAIN_MVIEW 不能直接告诉你“为什么没走物化视图”，但它能明确指出重写被拒绝的**具体技术原因**——只要看懂 MSGTXT 和 CAPABILITY_NAME = 'REWRITE' 对应的 POSSIBLE 值，就能排除 90% 的配置盲区。
查 QUERY_REWRITE_ENABLED 和会话级开关是否真生效
很多问题根本不在物化视图本身，而在参数没真正起作用。QUERY_REWRITE_ENABLED 是会话级行为，系统级设为 TRUE 不代表每个连接都继承。
- 运行
SELECT VALUE FROM V$PARAMETER WHERE NAME = 'query_rewrite_enabled'，确认返回的是'TRUE'（注意是字符串，不是布尔值） - 在执行目标 SQL 的同一会话中，立刻运行
SHOW PARAMETER query_rewrite_enabled，避免连接池复用旧会话 - 如果应用用 Druid/UCP，必须在数据源初始化 SQL 中显式加
ALTER SESSION SET QUERY_REWRITE_ENABLED = TRUE - 别信开发库配置——生产库可能仍为默认
FALSE，尤其升级后未同步 init.ora/spfile
用 DBMS_MVIEW.EXPLAIN_REWRITE 精准定位重写失败点
DBMS_MVIEW.EXPLAIN_MVIEW 是通用诊断，但对“重写失败”场景不够细；真正该用的是 DBMS_MVIEW.EXPLAIN_REWRITE，它专为某条 SQL + 某个 MV 组合做语义匹配分析。
- 先确保已运行
@?/rdbms/admin/utlxmv.sql创建MV_CAPABILITIES_TABLE - 执行：
BEGIN DBMS_MVIEW.EXPLAIN_REWRITE( query => 'SELECT region, SUM(amount) FROM sales WHERE sale_date >= DATE ''2024-01-01'' GROUP BY region', mv => 'MV_SALES_SUM' ); END; - 查
SELECT * FROM MV_CAPABILITIES_TABLE WHERE STATEMENT_ID = 'QSMQT'，重点看MSGTXT字段，例如："no match on table SALES"、"integrity violation: missing validated primary key"、"stale data: MV_SALES_SUM is stale" - 如果
MSGTXT含QSMQT_UNREWRITE，大概率是分区键表达式不一致或隐式类型转换导致语义断层
结合 QUERY_REWRITE_INTEGRITY 和约束状态交叉验证
即使参数全开、MV 定义正确，QUERY_REWRITE_INTEGRITY = ENFORCED（默认）也会因基表约束状态卡住重写——它要求主键/外键不仅存在，还必须 VALIDATED。
- 查基表约束：
SELECT CONSTRAINT_NAME, STATUS, VALIDATED FROM USER_CONSTRAINTS WHERE TABLE_NAME = 'SALES' AND CONSTRAINT_TYPE = 'P';
若VALIDATED = 'NOT VALIDATED'，重写会被静默跳过 - 修复方式：
ALTER TABLE sales ENABLE PRIMARY KEY VALIDATE（注意：VALIDATE 会锁表并校验全量数据） - 临时绕过验证（仅限可信环境）：
ALTER SESSION SET QUERY_REWRITE_INTEGRITY = TRUSTED，它接受RELY ENABLE NOVALIDATE约束 - 别设
FORCE给QUERY_REWRITE_ENABLED：它强制重写但跳过成本评估，可能让简单查询变慢
检查物化视图自身状态和统计信息
优化器不会考虑一个“不可信”的物化视图，哪怕语法完全匹配。STALENESS 状态和缺失统计信息是最常被忽略的硬性门槛。
- 查物化视图状态：
SELECT MVIEW_NAME, STALENESS, LAST_REFRESH_DATE FROM USER_MVIEWS WHERE MVIEW_NAME = 'MV_SALES_SUM'若STALENESS = 'UNUSABLE'或'FAILED'，重写直接被禁用 - 刷新它：
EXEC DBMS_MVIEW.REFRESH('MV_SALES_SUM', method => 'C')（先用 complete 强制拉齐数据） - 收集统计信息：
EXEC DBMS_STATS.GATHER_TABLE_STATS(ownname => USER, tabname => 'MV_SALES_SUM', granularity => 'ALL')否则 CBO 可能因基数估算严重失真而放弃重写，尤其在分区 MV 场景下 - 确认权限：
SELECT * FROM SESSION_ROLES中必须含QUERY REWRITE角色，且对 MV 有SELECT权限
最易被忽略的点是：EXPLAIN_REWRITE 输出里出现 "stale data" 时，很多人只刷新 MV，却忘了基表物化视图日志（MLOG$_SALES）可能已被 purge 或积压大量未消费记录，导致 MV 实际无法及时更新——这时得查 USER_MVIEW_LOGS 的 LOG_TABLE 并确认其数据量是否异常膨胀。
