oracle物化视图本身不支持直接partition by语法，唯一官方支持的分区方案是通过预建分区表+物化视图日志+on prebuilt table三步组合实现，核心在于分区由表控制、刷新由物化视图逻辑驱动。
materialized view 本身不支持直接声明 partition by 子句，也不能像普通表那样用 partition by range 语法定义分区。想让物化视图“具备分区效果”，必须借助预建表（on prebuilt table）+ 分区表 + 物化视图日志的组合方式。这是唯一被 oracle 官方支持且稳定可用的路径。
为什么不能直接对物化视图做分区？
Oracle 的 MATERIALIZED VIEW 是一个逻辑对象，其底层存储由系统自动管理——它没有 CREATE MATERIALIZED VIEW ... PARTITION BY ... 语法。你看到的“分区物化视图”实际是：一个已存在的、手工创建的分区表，再通过 ON PREBUILT TABLE 绑定为物化视图。物化视图本身不控制物理布局，只控制刷新逻辑和查询重写行为。
常见误解是以为加了 REFRESH FAST 就能自动分区，其实不然：FAST 刷新依赖物化视图日志（MLOG$），而日志本身也不分区；它只是记录基表 DML 的 rowid 或主键变更，与目标存储结构无关。
如何用预建分区表实现物化视图数据分流？
核心步骤是三步走：先建分区表 → 再建物化视图日志 → 最后用 ON PREBUILT TABLE 关联。整个过程要求基表有主键或唯一约束，且物化视图查询必须满足快速刷新限制（如不能含 SELECT *、聚合需带 GROUP BY 等）。
- 创建分区表（例如按时间范围）：
CREATE TABLE mv_sales_summary ( sale_month DATE, product_id NUMBER, total_amt NUMBER ) PARTITION BY RANGE (sale_month) ( PARTITION p_2025q1 VALUES LESS THAN (DATE '2025-04-01'), PARTITION p_2025q2 VALUES LESS THAN (DATE '2025-07-01'), PARTITION p_2025q3 VALUES LESS THAN (DATE '2025-10-01'), PARTITION p_2025q4 VALUES LESS THAN (DATE '2026-01-01') );
- 在基表（如
sales）上创建物化视图日志：CREATE MATERIALIZED VIEW LOG ON sales WITH PRIMARY KEY, ROWID, SEQUENCE (sale_date, product_id, amount) INCLUDING NEW VALUES;
- 基于预建表创建物化视图：
CREATE MATERIALIZED VIEW mv_sales_summary ON PREBUILT TABLE REFRESH FAST ON DEMAND ENABLE QUERY REWRITE AS SELECT TRUNC(sale_date, 'Q') sale_month, product_id, SUM(amount) total_amt FROM sales GROUP BY TRUNC(sale_date, 'Q'), product_id;
注意：TRUNC(sale_date, 'Q') 输出的是日期类型，可作为分区键；但若基表 sale_date 无索引或未启用统计信息，REFRESH FAST 可能退化为 COMPLETE，需检查 DBA_MVIEW_ANALYSIS 视图确认刷新类型是否生效。
分区表绑定物化视图后，刷新时数据会自动路由到对应分区吗？
不会自动路由。Oracle 在执行 REFRESH FAST 时，仍以整张预建表为单位操作，DML 变更会落在具体行所在的分区，但这个行为由分区键值决定，不是物化视图控制的——换句话说，分区路由完全由插入/更新语句中的 sale_month 值触发，和刷新动作无关。
这意味着：如果你的物化视图查询里没显式计算出分区键（比如漏了 TRUNC(sale_date, 'Q')），或者用了不可分区的表达式（如 TO_CHAR(sale_date, 'YYYY-MM') 返回字符串），那么所有数据都会落到 DEFAULT 分区（如果定义了），或报错 ORA-14400: inserted partition key does not map to any partition。
验证方法：
SELECT partition_name, num_rows FROM dba_tab_partitions WHERE table_name = 'MV_SALES_SUMMARY';刷新后观察各分区行数是否合理分布。
容易被忽略的关键点
真正卡住上线的往往不是语法，而是权限链和一致性约束：
-
CREATE MATERIALIZED VIEW用户必须对基表有SELECT权限，且基表所属用户需显式GRANT SELECT ON MLOG$_SALES TO mv_user（物化视图日志表名是MLOG$_） - 预建表的列名、数据类型、长度、空值性必须与物化视图查询结果**完全一致**，否则
ON PREBUILT TABLE会静默失败或报ORA-12082 -
ENABLE QUERY REWRITE不等于自动重写，还需确保QUERY_REWRITE_ENABLED=TRUE且初始化参数QUERY_REWRITE_INTEGRITY设置为TRUSTED或STALE_TOLERATED，否则优化器直接忽略物化视图 - 如果基表是远程数据库（DB Link），物化视图日志必须建在远程端，且远程用户需有
CREATE MATERIALIZED VIEW LOG权限——本地无法代建
分区 + 物化视图的组合不是“开箱即用”的功能，它把分区的物理管理权交还给 DBA，把刷新逻辑交给物化视图机制，二者边界清晰但协作脆弱。任何一环配置偏差，都会导致刷新失败、查询不走重写、甚至分区键值错乱。
