物化视图未被重写主因是“不能用”或“不值得用”：需确认QUERY_REWRITE_ENABLED为TRUE/FORCE、MV状态为NOT STALE、统计信息已更新且CASCADE为TRUE、查询谓词与MV定义严格语义等价。
物化视图建了、ENABLE QUERY REWRITE也加了，但执行计划里还是扫基表——问题大概率不在“有没有”，而在“能不能用”和“值不值得用”。
确认 QUERY_REWRITE_ENABLED 是否真生效
Oracle 默认关闭查询重写，ALTER SYSTEM SET QUERY_REWRITE_ENABLED = TRUE 是硬性前提，且需 DBA 权限。会话级设置（ALTER SESSION）只对当前连接有效，应用连池通常不会自动执行它。
- 查当前值：
SELECT VALUE FROM V$PARAMETER WHERE NAME = 'query_rewrite_enabled'，返回必须是TRUE或FORCE，不是数字也不是空 - 生产环境常踩坑：开发测试时手动
ALTER SESSION成功，上线后 JDBC 连接池未配置初始化语句，实际仍是默认FALSE -
FORCE模式会跳过成本比较，强制重写（慎用），但前提是物化视图本身状态合法、统计信息存在
检查物化视图状态与统计信息是否就绪
优化器看到物化视图“不可信”或“算不准成本”，会直接弃用——哪怕语法全对。
- 查状态：
SELECT MVIEW_NAME, STALENESS, STALE_SINCE FROM USER_MVIEWS WHERE MVIEW_NAME = 'YOUR_MV_NAME'，STALENESS必须是NOT STALE（QUERY_REWRITE_INTEGRITY=ENFORCED下）或至少是STALE（STALE_TOLERATED下） - 查统计信息：
SELECT NUM_ROWS, LAST_ANALYZED FROM DBA_TAB_STATISTICS WHERE TABLE_NAME = 'YOUR_MV_NAME'，若LAST_ANALYZED是刷新前时间，说明没更新；EXEC DBMS_STATS.GATHER_TABLE_STATS(ownname => 'SCHEMA', tabname => 'MV_NAME', cascade => TRUE)必须带cascade => TRUE，否则索引统计不生效 - 常见静默失败：COMPLETE 刷新后未收集统计，优化器误判 MV 访问成本远高于基表，宁可全表扫也不走 MV
验证查询是否满足语义等价重写条件
Oracle 不做逻辑推导，只做结构匹配。长得像 ≠ 能重写。
- WHERE 中不能出现 MV 定义里没有的列，比如 MV 只有
sale_month，查询却写WHERE sale_date >= DATE '2024-01-01'→ 失败 - 避免函数包裹分区键或索引列：
WHERE TRUNC(dt) = DATE '2024-01-01'无法命中按dt分区的 MV；应改写为WHERE dt >= DATE '2024-01-01' AND dt - 用
DBMS_MVIEW.EXPLAIN_REWRITE查失败原因，重点看MESSAGE字段，例如QSM-01150: no suitable materialized view found或partition key not used - 执行
EXPLAIN PLAN FOR后查PLAN_TABLE，确认OBJECT_NAME是你的 MV 名，且操作类型含MATERIALIZED VIEW REWRITE
排查索引失效与分区剪枝脱钩问题
MV 表上有索引，不代表查询就能用上；分区剪枝没触发，往往是因为重写根本没发生。
- 刷新后索引变
UNUSABLE很常见：查SELECT INDEX_NAME, STATUS FROM DBA_INDEXES WHERE TABLE_NAME = 'YOUR_MV_NAME'，状态为UNUSABLE就得ALTER INDEX idx_name REBUILD - 分区剪枝发生在 MV 被访问时，不是基表。如果重写没触发，压根不会读 MV，自然无剪枝可言
- 确保查询中过滤的列名与 MV DDL 中的分区键列名**完全一致**（包括大小写和双引号），例如 MV 定义用
"EVENT_TIME"，查询也必须写WHERE "EVENT_TIME" >= ... -
QUERY_REWRITE_INTEGRITY设为TRUSTED可绕过部分校验，但数据一致性风险需人工兜底——它不解决重写不触发的问题，只放宽触发门槛
最易被忽略的一点：物化视图不是“建完即用”的缓存，而是一个需要持续维护的状态对象。索引状态、统计时效、谓词字面匹配、参数开关层级——任一环节断开，重写就会静默失效。验证必须从 EXPLAIN_REWRITE 和 PLAN_TABLE 出发，而不是只盯着 DDL 是否写了 ENABLE QUERY REWRITE。
