Oracle 12c 中物化视图不支持直接组合分区，必须基于已分区基表构建并利用分区裁剪提升性能，或改用分区表+分区交换模拟其行为。
MATERIALIZED VIEW 本身不支持直接定义组合分区（如 RANGE-HASH、RANGE-LIST），这是 Oracle 12c 的硬性限制。你不能在 CREATE MATERIALIZED VIEW 语句里写 PARTITION BY RANGE(time_col) SUBPARTITION BY HASH(id) —— 语法直接报错 ORA-00922: missing or invalid option。
必须换思路：把物化视图建在**已分区的基表上**，再通过物化视图的刷新机制继承物理结构优势，而非给物化视图本身分区。
为什么物化视图不能直接组合分区
Oracle 的物化视图本质是“可刷新的查询结果表”，其存储结构由底层基表和刷新逻辑共同决定。MATERIALIZED VIEW 不是普通表，不支持 PARTITION BY 子句（哪怕 12c 也不支持）。官方文档明确列出支持分区的数据库对象中，MATERIALIZED VIEW 不在列表内。
常见误操作包括：
- 复制普通表的
PARTITION BY语法到CREATE MATERIALIZED VIEW→ 报错ORA-00922 - 试图对已存在的物化视图执行
ALTER MATERIALIZED VIEW ... SPLIT PARTITION→ 报错ORA-32313: cannot alter materialized view with partitioning - 用
DBMS_MVIEW.EXPLAIN_MVIEW检查时发现partition_by字段始终为NULL
可行路径：基于已分区基表构建物化视图
真正能落地的组合分区策略，依赖于基表本身已按业务维度合理分区（例如按时间 RANGE 分区 + 按客户 ID HASH 子分区），然后让物化视图查询这些分区表，并利用分区裁剪提升刷新与查询效率。
关键实操点：
- 基表必须是真正的组合分区表（如
PARTITION BY RANGE(dt) SUBPARTITION BY HASH(cust_id) SUBPARTITIONS 8） - 物化视图定义中显式引用分区键字段（如
SELECT dt, cust_id, SUM(sales) FROM sales_part GROUP BY dt, cust_id），否则优化器无法下推分区裁剪 - 刷新时使用
ATOMIC_REFRESH => FALSE，避免全量重建；配合DBMS_MVIEW.REFRESH_DEPENDENT可实现只刷新受影响的基表分区对应的数据块 - 若基表启用了
HEAT_MAP和 ILM 策略，物化视图刷新作业会自动跳过只读冷分区（前提是查询条件含分区键谓词）
替代方案：用分区表模拟物化视图行为
当业务强依赖“分区级增量刷新+组合分区结构”时，更可控的做法是放弃 MATERIALIZED VIEW，改用带调度的 INSERT /*+ APPEND */ INTO ... SELECT + 分区交换（EXCHANGE PARTITION）。
示例流程：
- 新建一张组合分区表
mv_sales_summary，结构与物化视图输出一致 - 每日凌晨运行脚本：
INSERT /*+ APPEND */ INTO mv_sales_summary PARTITION FOR (DATE'2026-09-28') SELECT ... FROM sales_part WHERE dt = DATE'2026-09-28' - 插入完成后，用
ALTER TABLE mv_sales_summary EXCHANGE PARTITION ... WITH TABLE tmp_mv_load快速上线新分区 - 旧分区可单独压缩或迁移：
ALTER TABLE mv_sales_summary MOVE PARTITION p_2025_q1 COMPRESS FOR ARCHIVE LOW TABLESPACE ts_cold UPDATE INDEXES
这个方案完全绕开物化视图限制，且每个步骤都可监控、可回滚、可并行，适合亿级数据场景。
容易被忽略的性能陷阱
即使基表已组合分区，物化视图查询仍可能全表扫描——原因往往不在分区本身，而在谓词写法：
-
WHERE TRUNC(dt) = DATE'2026-09-28'→ 破坏分区裁剪，索引/分区都失效 -
WHERE dt BETWEEN :start AND :end→ 正确，但需确保:start和:end是字面量或绑定变量且类型匹配（DATE，非VARCHAR2） - 物化视图含聚合 +
GROUP BY时，若未在基表上建好本地分区索引（如LOCAL INDEX ON sales_part(dt, cust_id)），GROUP BY 会变成单线程排序 - 刷新日志（
MLOG$_SALES_PART）若未分区，大基表的快速刷新可能因日志表热点而卡住
最隐蔽的问题是：物化视图日志默认不继承基表分区属性，CREATE MATERIALIZED VIEW LOG ON sales_part 创建的日志表仍是堆表——海量变更下，日志插入会成为瓶颈。必须手动重建为分区日志表并重挂日志，这一步文档极少提及，但生产环境几乎必做。
