explain_rewrite 返回空结果或no_rewrite_reason通常因query_rewrite_enabled=false、缺少query rewrite权限、或物化视图disabled/stale；rewrite_cannot_be_performed表示查询与mv结构不匹配，如列缺失、聚合不一致、连接条件不可推导；unknown_rewrite_reason需结合10053 trace定位。
explain_rewrite 返回空结果或 no_rewrite_reason 是什么
这通常不是查询写错了，而是优化器压根没触发重写逻辑。常见原因是 query_rewrite_enabled 参数为 false，或当前用户没被授予 query rewrite 权限。另外，如果物化视图（mv）状态是 disabled 或 stale，explain_rewrite 也会跳过它，不报错也不提示——只默默返回空。
- 检查权限：
SELECT * FROM USER_ROLE_PRIVS WHERE GRANTED_ROLE = 'QUERY REWRITE'; - 确认参数：
SHOW PARAMETER QUERY_REWRITE_ENABLED;（必须是TRUE或FORCE） - MV 必须是
ENABLED且VALID状态，用SELECT MVIEW_NAME, STALENESS, STALE_SINCE FROM USER_MVIEWS;查
为什么 EXPLAIN_REWRITE 显示 REWRITE_CANNOT_BE_PERFORMED
这是最常被误读的提示。它不表示语法错误，而是说明“规则存在，但当前查询结构和 MV 定义不匹配”。典型原因包括：查询里用了 MV 中未包含的列、聚合函数不一致（比如 MV 用 SUM(sales)，而查询写了 COUNT(*)）、或者连接条件中存在无法推导等价性的表达式（如 t1.id + 1 = t2.ref_id）。
- 确保查询 SELECT 列全部来自 MV 的 SELECT 列（或可由其推导，如
SUM(x+y)≠SUM(x)+SUM(y)，后者才可能重写） - WHERE 条件里的谓词必须能“下推”到 MV 源表；含函数索引列（如
UPPER(name)）需 MV 显式包含该表达式 - 避免在 JOIN ON 中使用非等值或跨表计算，
EXPLAIN_REWRITE不分析语义等价性，只做结构比对
如何用 DBMS_MVIEW.EXPLAIN_REWRITE 配合系统资源判断匹配度
这个包本身不暴露资源消耗，但它输出的 REWRITE_LEVEL 和 REWRITE_MECHANISM 字段间接反映代价策略。比如 REWRITE_LEVEL = 'TEXT_MATCH' 表示仅靠文本匹配就完成重写，开销最小；而 'GENERAL_PLAN_MATCH' 意味着优化器做了完整执行计划比对，会消耗更多 CPU 和 shared pool 内存。
- 高并发 OLTP 环境下，频繁调用
DBMS_MVIEW.EXPLAIN_REWRITE可能加剧 library cache latch 争用，建议只在问题复现时单次执行 - 如果输出中出现大量
REWRITE_MECHANISM = 'FULL_TEXT_MATCH'，说明 MV 设计偏窄，应考虑扩展覆盖范围（如增加常用过滤字段到 MV SELECT 列） -
NO_REWRITE_REASON为RESOURCE_LIMIT_EXCEEDED时，实际是 shared pool 不足导致重写分析中途放弃，不是 SQL 本身问题
EXPLAIN_REWRITE 输出里 UNKNOWN_REWRITE_REASON 怎么办
这不是 bug，是 Oracle 故意留的兜底标记——意味着重写失败路径未被预设分支捕获。此时必须结合 10053 事件跟踪，否则无法定位真实原因。
- 立即执行：
ALTER SESSION SET EVENTS '10053 trace name context forever, level 1';，再跑原查询 - 在 trace 文件里搜索
query rewrite和mv:，重点关注 “cannot use mv” 后面紧跟的子句（比如 “join predicate not transitive”） - 注意：10053 不记录
EXPLAIN_REWRITE调用本身，只记录真实查询优化过程，所以必须对原始 SQL 打点
真正难处理的是那些依赖统计信息质量的隐式限制——比如 MV 基表的 NUM_DISTINCT 严重失真，会导致优化器误判重写收益，这种问题不会出现在 EXPLAIN_REWRITE 输出里，只能靠 DBMS_STATS 抽样校验和 trace 交叉验证。
