DBMS_MVIEW.EXPLAIN_MVIEW是唯一能在刷新前诊断物化视图无法FAST刷新原因的工具，通过检查mv_capabilities_table中REFRESH_FAST行的possible值和msgtxt内容，结合RECOMMENDATION字段精准定位日志缺失、SQL结构限制等根因。
DBMS_MVIEW.EXPLAIN_MVIEW 能提前暴露“本该快却变慢”的根因
物化视图刷新慢，90%不是性能问题，而是本该走 fast 却被迫退化成 complete。而 dbms_mview.explain_mview 就是唯一能在刷新前告诉你“为什么不能快”的工具——它不跑实际刷新，只做定义层校验，避免你等半小时才发现刷的是全量。
执行前必须先建解释表（Oracle 官方要求）：
CREATE TABLE mv_capabilities_table ( statement_id VARCHAR2(30), mvowner VARCHAR2(30), mvname VARCHAR2(30), capability_name VARCHAR2(30), possible CHAR(1), related_text VARCHAR2(2000), msgtxt VARCHAR2(2000) );
然后运行：
EXEC DBMS_MVIEW.EXPLAIN_MVIEW('MV_SALES_SUMMARY');关键不是看有没有报错，而是查结果里 CAPABILITY_NAME = 'REFRESH_FAST' 这一行的 possible 值和 msgtxt 内容。
MSGTXT 里出现这些提示，基本就锁定了慢的源头
MSGTXT 是人话诊断，比错误码直接十倍。常见几类提示对应明确动作：
-
"REFRESH FAST IS NOT POSSIBLE"→ 不是配置漏了，是定义或基表状态硬性不满足，必须逐条查RECOMMENDATION -
"NO LOG ON BASE TABLE"→ 至少一张基表没建物化视图日志，比如MLOG$_ORDERS根本不存在 -
"missing rowid"或"sequence column not logged"→ 日志建了但缺ROWID或SEQUENCE关键字段 -
"POTENTIAL FAST REFRESH"但实际没走 → 日志有积压（LAST_PURGE_DATE滞后）、DML 后没提交、或日志表被手动清空过
查 RECOMMENDATION 字段才能知道具体哪一行 SQL 卡住
EXPLAIN_MVIEW 输出里真正要盯的是 RECOMMENDATION 字段（需从 MVIEW_EXCEPTIONS 表查，或用 q'[] 语法捕获）。它会精准指出语法级限制点：
-
"join not supported"→ 查询含LEFT JOIN或UNION ALL，Oracle 内核级禁用 FAST -
"expression not allowed in select list"→ 用了UPPER(name)、SYSDATE等非确定性表达式 -
"aggregate not supported"→ 有SUM()或GROUP BY，且没同时满足COUNT(*)+ 所有GROUP BY列的COUNT(col) -
"subquery not supported"→ 出现EXISTS、IN、NOT EXISTS，直接导致fastrefreshable = FALSE
RELATED_TEXT 会标出触发限制的具体 SQL 片段，比如第 3 行的 SELECT * FROM orders o LEFT JOIN customers c —— 比翻文档快得多。
REFRESH_FAST 的 POSSIBLE='N' 是判决书，但背后可能有多个断点
一个物化视图能否快速刷新，取决于整条依赖链：每张基表的日志结构、主键/ROWID 可见性、JOIN 类型、表达式确定性、甚至远程 DBLINK 的版本兼容性。所以即使 POSSIBLE = 'N'，也不能只改一个地方就完事。
实操必须闭环验证：
- 先查
SELECT capability_name, possible, msgtxt FROM mv_capabilities_table WHERE statement_id = 'QSMQT_EXPLAIN_MVIEW' AND possible = 'N' - 根据
msgtxt和RECOMMENDATION修复（如补日志：CREATE MATERIALIZED VIEW LOG ON t1 WITH ROWID, SEQUENCE(id) INCLUDING NEW VALUES） - 再跑一遍
EXPLAIN_MVIEW，确认REFRESH_FAST行的possible变成'Y'，且所有相关CAPABILITY_NAME都不再为'N'
最容易被忽略的是：哪怕只有一张基表的日志缺 ROWID，整个物化视图就退化为 COMPLETE，不会部分生效；外连接或子查询这类限制，也不是调参数能绕过的硬边界。
