物化视图需手动分区并确保查询条件直引用分区键才能实现分区裁剪；若定义缺分区列、条件用函数包装或底层表未实际分区，将导致全表扫描。
物化视图本身不自动继承基表分区结构，想让它按时间范围快速响应“只查最近N个月”的查询，必须手动让物化视图的底层存储具备分区能力，并确保查询能触发分区裁剪（partition pruning）。
为什么物化视图查询不走分区裁剪
即使基表按SALES_DATE做了范围分区，物化视图仍可能全表扫描，常见原因有三个：
- 物化视图定义中没包含分区键列（如
SELECT product_id, amount FROM sales漏了SALES_DATE），优化器无法将WHERE SALES_DATE >= DATE '2026-06-01'下推到MV上 - 查询条件用了函数包装，比如
WHERE TRUNC(SALES_DATE) = DATE '2026-06-01'，会阻断裁剪 - 物化视图底层表未实际分区——它只是个普通堆表，哪怕逻辑上“应该”按月分，物理上仍是单段
必须用ON PREBUILT TABLE + 手动分区
Oracle 不允许直接对物化视图做ALTER TABLE ... ADD PARTITION，所以得从建表阶段控制物理结构：
- 先建一个与物化视图结构一致的分区表：
CREATE TABLE mv_sales_monthly (sales_date DATE, product_id NUMBER, amount NUMBER) PARTITION BY RANGE (sales_date) (PARTITION p_2025 VALUES LESS THAN (DATE '2026-01-01'), PARTITION p_2026_q2 VALUES LESS THAN (DATE '2026-07-01'), ...) - 在该表上创建索引、约束（如
LOCAL索引）、并收集统计信息 - 再用
CREATE MATERIALIZED VIEW mv_sales_monthly ON PREBUILT TABLE REFRESH FAST ON DEMAND AS SELECT sales_date, product_id, amount FROM sales WHERE sales_date >= DATE '2025-01-01' - 注意：WHERE 条件里保留历史范围，是为了让物化视图内容与分区边界对齐，避免跨分区数据混杂
分区键列和日志必须严格对齐
要支持后续增量刷新且保持裁剪能力，物化视图日志不能只建在基表上就完事：
- 基表日志必须含分区键：
CREATE MATERIALIZED VIEW LOG ON sales WITH ROWID, SEQUENCE(sales_date) INCLUDING NEW VALUES -
SEQUENCE参数里显式列出sales_date，否则DBMS_MVIEW.REFRESH无法识别分区级变更 - 物化视图定义中
SELECT列表必须包含sales_date，且类型与基表完全一致（不能是TRUNC(sales_date)或TO_CHAR） - 如果基表是
INTERVAL分区，日志仍建在主表名上，无需为每个自动新增分区单独操作
查询时如何确认真的走了分区裁剪
别信执行计划里有没有MV_SALES_MONTHLY字样，重点看是否真正剪枝：
- 运行
EXPLAIN PLAN FOR SELECT * FROM mv_sales_monthly WHERE sales_date BETWEEN DATE '2026-06-01' AND DATE '2026-06-30';后查SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY); - 关键指标：输出中要有
PSTART和PSTOP值，且不是1和ALL；理想情况是PSTART = 3,PSTOP = 3（表示只扫第3个分区） - 若看到
ACCESS PREDICATES为空，或PLAN_TABLE_OUTPUT里出现PARTITION RANGE ALL，说明裁剪失败，大概率是物化视图表没分区，或查询条件没直引用列 - 补充验证：查
SELECT partition_name FROM user_tab_partitions WHERE table_name = 'MV_SALES_MONTHLY'，确认该表确实是分区表而非普通表
最容易被忽略的一点：物化视图预建表（即ON PREBUILT TABLE所指的物理表）一旦建好分区结构，后续就不能再改分区策略；如果业务后来要求按季度而非月份切分，只能重建整个链路，包括日志、物化视图定义和填充逻辑。
