物化视图不自动继承分区剪枝能力，必须先确保查询重写成功触发，再谈剪枝；重写失败常见原因包括权限不足、QUERY_REWRITE_INTEGRITY设置过严、使用非确定性函数或表达式不匹配等。
物化视图本身不自动继承分区剪枝能力
建完 CREATE MATERIALIZED VIEW ... PARTITION BY RANGE (time_id) 并不等于查询就能自动剪枝。Oracle 的查询重写引擎（query rewrite）和分区剪枝（partition pruning）是两个独立阶段：重写决定“要不要走 MV”，剪枝决定“走 MV 时扫哪些分区”。如果重写没触发，优化器压根不会访问 MV，剪枝无从谈起。
常见错误现象是：MV 已按 time_id 分区，但 SELECT * FROM mv WHERE time_id >= DATE '2024-01-01' 执行计划里 OBJECT_NAME 显示基表名，PARTITION_START/PARTITION_STOP 是 KEY（表示未剪枝），甚至 EXPLAIN PLAN 根本不提 MV。
- 必须先用
DBMS_MVIEW.EXPLAIN_REWRITE验证重写是否成功，只看EXPLAIN PLAN会误判 - MV 定义中的分区键列名必须与查询中 WHERE 子句的列名**完全一致**（包括大小写、是否带双引号）
- 禁止在查询中对分区键使用任何函数，例如
TRUNC(time_id)、TO_CHAR(time_id, 'YYYYMM')、NVL(time_id, sysdate)—— 这些都会切断剪枝链 - 若 MV 是基于 ON PREBUILT TABLE 创建，需手动对底层表执行
ALTER TABLE ... PARTITION BY ...，否则物理存储仍是堆表
为什么 DBMS_MVIEW.EXPLAIN_REWRITE 显示 UNREWRITTEN？
不是 MV 没建好，而是重写被静默跳过。最常被忽略的三个原因：
-
QUERY_REWRITE_ENABLED为FALSE，或用户缺少QUERY REWRITE权限（注意：不是CREATE MATERIALIZED VIEW权限） -
QUERY_REWRITE_INTEGRITY设为ENFORCED，但基表上缺失RELY约束（如ALTER TABLE sales MODIFY (time_id NOT NULL RELY)），导致 Oracle 不敢信任 MV 数据一致性 - 查询中含非确定性函数，如
SYSDATE、USER、ROWNUM，或用了+ RESULT_CACHE提示 —— 后者会直接绕过整个重写流程
验证方式：运行 EXEC DBMS_MVIEW.EXPLAIN_REWRITE('SELECT ...', 'MV_NAME');，再查 REWRITE_TABLE 中 REWRITE_MECHANISM 字段。只有值为 TEXT_MATCH 或 GENERAL 才算真正匹配；UNREWRITTEN 附带的 MESSAGE 字段通常会明确提示 “partition key not used” 或 “expression not supported”。
高频多维报表该建几个物化视图？
别建一个“大而全”的 MV 覆盖所有维度组合。Oracle 查询重写器只匹配单个 MV，不拼接、不合并多个 MV 结果。
- 按实际业务查询模式拆分：例如“日粒度+区域+产品线销售额汇总” → 单独建
mv_sales_daily_region_prod，GROUP BY time_id, region, product_line - 避免在 MV 定义中用函数处理时间字段：不要写
TO_CHAR(time_id, 'YYYYMM')，改用TRUNC(time_id, 'MM')或EXTRACT(YEAR FROM time_id), EXTRACT(MONTH FROM time_id)，否则重写失败且无法剪枝 - 对时间范围查询高频的 MV，显式加
PARTITION BY RANGE (time_id)，并配合DBMS_MVIEW.REFRESH_FAST_AFTER_INSERT实现分区级增量刷新 - 每个 MV 上手动创建复合索引，顺序按高频查询的过滤+排序+分组列排列，例如
CREATE INDEX idx_mv_drp ON mv_sales_daily_region_prod (time_id, region, product_line)
分区数超 1024 后，物化视图查询反而变慢怎么办？
这不是 MV 本身的问题，而是 Oracle 解析含大量分区对象的 SQL 时，优化器需为每个相关分区生成执行计划分支，导致硬解析 CPU 暴涨、library cache lock 等待加剧 —— 即使你只查一天数据，它也可能扫描全部分区元数据。
- 对已知时间范围的查询，加
/*+ NO_EXPAND */hint，阻止谓词自动展开成多个分区分支 - 把字面量过滤改为绑定变量：将
WHERE time_id BETWEEN DATE '2024-01-01' AND DATE '2024-01-31'改为WHERE time_id BETWEEN :start_dt AND :end_dt，并确保变量类型为DATE - 对固定周期聚合（如每日汇总），直接建按天分区的 MV，让应用查 MV 而非原始超大分区表 —— 把解析开销转移到可控的刷新阶段
- 长期需清理冷分区：用
ALTER TABLE t EXCHANGE PARTITION p_old WITH TABLE t_archive导出后DROP PARTITION，比 DELETE 更快且不锁表
真正容易被忽略的是：分区剪枝生效的前提，是查询重写先成功；而重写成功的前提，是语义匹配、权限、完整性约束、无干扰机制（如 RESULT_CACHE）四者同时满足。少一个，后面所有优化都白搭。
