DBMS_MVIEW.EXPLAIN_REWRITE 是 Oracle 唯一能明确告知“为何未重写”的工具，精准分类失败原因：no match、stale data 或 integrity violation；需确保 QUERY_REWRITE_ENABLED 会话级生效、QUERY_REWRITE_INTEGRITY 匹配约束状态，并严格保证物化视图与查询语义等价。
用 DBMS_MVIEW.EXPLAIN_REWRITE 直接看失败理由
别靠猜，也别只看执行计划里有没有物化视图名——DBMS_MVIEW.EXPLAIN_REWRITE 是 Oracle 唯一能告诉你“为什么没重写”的内置工具。它不返回模糊提示，而是明确分类：是 no match（语义不等价）、stale data（物化视图过期）、还是 integrity violation（约束或参数不满足）。
实操建议：
- 先确保会话已启用重写：
ALTER SESSION SET QUERY_REWRITE_ENABLED = TRUE - 调用时传入完整 SQL 字符串和物化视图名，例如：
DBMS_MVIEW.EXPLAIN_REWRITE('SELECT SUM(amount) FROM sales WHERE region = ''CN''', 'mv_sales_sum') - 查结果表
MV_CAPABILITIES_TABLE（需提前建），重点关注MSGTXT列，它比CAPABILITY_NAME更直白 - 注意：该过程不验证权限，若用户无
QUERY REWRITE权限，会静默返回UNREWRITTEN，不是 bug，是设计
检查 QUERY_REWRITE_ENABLED 是否真在生效会话中
QUERY_REWRITE_ENABLED 是会话级参数，系统级设为 TRUE 不代表每个连接都继承。尤其在使用 Druid、UCP 等连接池时，应用启动后新建的连接默认沿用数据库初始值（某些版本默认 FALSE），而不会自动执行 ALTER SESSION。
实操建议：
- 在目标会话中直接查：
SELECT VALUE FROM V$PARAMETER WHERE NAME = 'query_rewrite_enabled'—— 注意返回的是字符串'TRUE'，不是布尔或数字 - 确认当前会话是否被覆盖：
SELECT SYS_CONTEXT('USERENV', 'SESSIONID') FROM DUAL对应的会话，再查V$SES_OPTIMIZER_ENV中query_rewrite_enabled的值 - 不要依赖 JDBC URL 里的
oracle.jdbc.defaultRowPrefetch类参数，它对重写开关无效
验证 QUERY_REWRITE_INTEGRITY 设置是否匹配数据现状
QUERY_REWRITE_INTEGRITY 决定优化器“敢不敢信”物化视图的数据一致性。设成 ENFORCED（默认）时，要求基表主键/外键已 VALIDATED，且物化视图日志存在；但多数生产环境基表约束是 RELY ENABLE NOVALIDATE，这时必须显式设为 TRUSTED，否则重写静默跳过。
实操建议：
- 先临时在会话级试：
ALTER SESSION SET QUERY_REWRITE_INTEGRITY = TRUSTED，再跑EXPLAIN_REWRITE看是否从integrity violation变成rewritten - 若确认业务能接受该级别信任，再全局修改：
ALTER SYSTEM SET QUERY_REWRITE_INTEGRITY = TRUSTED；别设STALE_TOLERATED，除非是离线分析场景 - 检查基表约束状态：
SELECT CONSTRAINT_NAME, VALIDATED, RELY FROM DBA_CONSTRAINTS WHERE TABLE_NAME = 'YOUR_TABLE'，RELY为YES且VALIDATED为NO时，ENFORCED必然失败
确认物化视图定义与查询语义是否严格等价
Oracle 查询重写不是“模糊匹配”，而是基于确定性语义推导。哪怕只是列别名不同、表达式写法稍异（如物化视图用 UPPER(name)，查询写 name），或用了非确定性函数（SYSDATE、ROWNUM、DBMS_RANDOM.VALUE），都会导致重写被禁用。
实操建议：
- 对比物化视图
SELECT列和查询中的对应字段：必须类型一致、NULL 性一致、表达式完全相同（包括括号位置） - 禁止在物化视图定义中使用
UNION ALL—— 它破坏单源语义，19c 仍不支持基于 UNION ALL 视图的重写 - 聚合类物化视图中，所有参与列必须显式处理 NULL，例如用
NVL(col, 0)替代裸列，否则刷新逻辑可能失效，间接导致重写被绕过 - 如果查询含绑定变量，注意
EXPLAIN_REWRITE传入的是字面值，不代表真实执行时的行为；必要时用autotrace on explain+ 实际执行双重验证
真正卡住排查进度的，往往不是参数没开，而是重写决策发生在 SQL 解析阶段，而那个阶段所依赖的约束状态、日志完备性、甚至会话初始化方式，全都在你没注意到的地方悄悄失效。
