物化视图必须手动分区才能利用基表分区剪枝；需用on prebuilt table方式创建，确保分区键、数量及边界与基表对齐，且定义中不可含表达式列，否则谓词无法下推。
物化视图必须手动分区，否则无法利用基表的分区剪枝
Oracle 的物化视图本身不自动继承基表的分区结构。哪怕基表是按 log_date RANGE 分区的 TB 级表，直接创建的物化视图底层存储表仍是单一分区——查询时无法剪枝，全量扫描照旧发生。
实操建议：
- 用
ON PREBUILT TABLE方式创建物化视图，先建好已分区的目标表（如按相同log_dateRANGE 分区） - 确保该表的分区键、分区数量、边界值与基表对齐，否则后续刷新或查询重写可能失效
- 物化视图定义中不能含表达式列（如
TRUNC(log_date)），否则 Oracle 无法将谓词下推到分区键上 - 验证是否生效：执行
EXPLAIN PLAN FOR SELECT ... WHERE log_date >= DATE '2026-09-01'，看执行计划中是否出现PARTITION RANGE ITERATOR
FAST 刷新失败？大概率是物化视图日志缺 ROWID 或主键
对分区表建 FAST 刷新物化视图，ORA-12015 或 ORA-12052 错误不是因为 SQL 复杂，而是基表没配好日志。分区表不自动提供行级变更元数据，必须显式补全。
实操建议：
- 基表必须有主键或唯一约束（
ALTER TABLE t ADD CONSTRAINT pk_t PRIMARY KEY (id)） - 日志创建语句必须显式包含
ROWID和所有 SELECT 中用到的列：CREATE MATERIALIZED VIEW LOG ON t WITH PRIMARY KEY, ROWID, SEQUENCE(id, log_date, amount) INCLUDING NEW VALUES - 不要用
SYSDATE、子查询、聚合函数——这些会强制退化为 COMPLETE 刷新 - INTERVAL 分区表的日志仍建在主表名上，无需为每个分区单独操作
索引建在哪？不是建在 MV 名字上，而是建在底层段名上
Oracle 中物化视图本质是表，但它的名字（如 mv_daily_sales）只是别名；真实数据存在系统生成的段名下（可通过 SELECT mview_name, table_name FROM user_mviews 查）。直接对 mv_daily_sales 建索引会报错或无效。
实操建议：
- 先查出物化视图对应的实际表名：
SELECT table_name FROM user_mviews WHERE mview_name = 'MV_DAILY_SALES' - 索引必须建在这个
table_name上，例如：CREATE INDEX idx_mv_region_type ON mv_daily_sales_tab (region, product_type, sales_amt) - 高频聚合查询优先覆盖过滤 + 分组 + 排序字段组合，避免为高基数 ID 单独建索引
- 若启用查询重写（
QUERY REWRITE），索引列不能是表达式（如UPPER(name)），否则重写可能跳过该 MV
TB 级首次加载别用 REFRESH COMPLETE，锁表几小时是常态
对超大分区表，首次构建物化视图若走 REFRESH COMPLETE，Oracle 会 truncate + insert 全量，期间锁表、阻塞业务、极易超时失败。
实操建议：
- 提前建好空的分区表：
CREATE TABLE mv_target PARTITION BY RANGE(log_date) ... AS SELECT * FROM src_table WHERE 1=0 - 在该表上建好索引、约束、统计信息
- 用
ON PREBUILT TABLE创建 MV：CREATE MATERIALIZED VIEW mv_target ON PREBUILT TABLE REFRESH FAST ON DEMAND AS SELECT ... - 首次填充用并行 INSERT：
INSERT /*+ APPEND PARALLEL(8) */ INTO mv_target SELECT ...，再执行DBMS_MVIEW.REFRESH('mv_target', 'F')
真正容易被忽略的是：物化视图的分区边界和基表不一致时，即使语法通过，后续按时间范围查询也可能扫全分区——这比没建索引还隐蔽。
