物化视图未被重写主因是QUERY_REWRITE_ENABLED关闭或会话级设为FALSE；QSM-01150需结合MESSAGE和REWRITE_MECHANISM分析；语义等价性要求字面完全一致，含函数、大小写、空格均需匹配。
为什么查询没走物化视图，执行计划里全是基表？
这不是物化视图建得不对，而是 Oracle 优化器压根没把它纳入候选范围——常见于 QUERY_REWRITE_ENABLED 被关掉、或会话级被显式设为 FALSE。先确认这个开关是否真开着：SELECT value FROM v$parameter WHERE name = 'query_rewrite_enabled'；再查当前会话：SELECT sid, name, value FROM v$ses_optimizer_env WHERE sid = SYS_CONTEXT('USERENV', 'SID') AND name = 'query_rewrite_enabled'。会话级设置优先级高于实例级，哪怕初始化参数是 TRUE，只要某条 SQL 所在 session 执行过 ALTER SESSION SET query_rewrite_enabled = FALSE，它就彻底失效。
DBMS_MVIEW.EXPLAIN_REWRITE 返回 QSM-01150 怎么解读？
这个错误码本身不指明具体原因，必须看它附带的 MESSAGE 和 REWRITE_MECHANISM 字段。运行：EXEC DBMS_MVIEW.EXPLAIN_REWRITE('SELECT * FROM sales WHERE dt >= DATE ''2024-01-01''', 'MV_SALES')，然后查 MV_CAPABILITIES_TABLE。重点关注：
-
REWRITE_MECHANISM = 'NO_REWRITE'：说明重写引擎根本没启动，大概率是QUERY_REWRITE_INTEGRITY级别太高（如ENFORCED）但基表约束未VALIDATED -
MESSAGE含partition key not used：查询过滤列和物化视图分区键名不一致，或用了函数包装（如TRUNC(dt)） -
MESSAGE含stale data：物化视图状态是STALE，而当前QUERY_REWRITE_INTEGRITY不允许用陈旧数据 -
MESSAGE含integrity violation：基表缺主键/外键约束，或约束是NOVALIDATE且没加RELY
物化视图已刷新且状态为 FRESH，但重写仍失败？
这往往卡在“语义等价性”上——Oracle 要求查询中的表达式与物化视图定义中对应列**字面完全一致**。比如物化视图定义里是 UPPER(customer_name)，那查询里也必须写 UPPER(customer_name) = 'ABC'，不能写 customer_name = 'abc'（即使数据库有大小写不敏感设置）。同样，如果物化视图按 TO_CHAR(sale_dt, 'YYYY-MM') 分区，查询就必须用相同函数+格式串，不能换成 EXTRACT(YEAR FROM sale_dt) = 2024。这些差异不会报错，只会静默跳过重写。
执行计划显示走了物化视图，但没触发分区剪枝？
说明重写发生了，但分区裁剪没生效。先确认执行计划中 OBJECT_NAME 确实是物化视图名（不是基表），再看 PARTITION_START 和 PARTITION_STOP 字段：若显示 KEY 或 ROW LOCATION，代表没剪枝；若显示数字（如 3–5），才是真裁剪。常见断点：
- 物化视图统计信息陈旧：
DBMS_STATS.GATHER_TABLE_STATS必须带GRANULARITY => 'ALL'，否则只更新全局统计，CBO 无法估算单个分区基数 - 查询中对分区键列做了隐式类型转换，比如
WHERE dt = '2024-01-01'（字符串） vs 物化视图分区键是DATE类型 - 物化视图定义用了虚拟列或函数索引作为分区键，Oracle 重写引擎通常忽略这类结构
重写机制依赖的是“字面匹配 + 约束信任 + 统计可信”，三者缺一不可。最易被忽略的是：约束必须 VALIDATED（不是只 ENABLE），日志必须存在且覆盖所有 JOIN/GROUP BY 列，而查询里的每个字符都得和物化视图定义对得上——连空格和大小写都不能差。
