oracle 11g多分区基表物化视图调优需满足三条件：显式分区（on prebuilt table）、物化视图日志含分区键及所有查询列、query_rewrite_integrity设为stale_tolerated，并手动同步索引与分区级统计信息。
Oracle 11g 中对多分区基表的物化视图调优，核心瓶颈不在“多分区”本身，而在于物化视图是否真正继承了分区结构、能否走分区裁剪、以及快速刷新是否实际生效——三者缺一不可。直接在分区表上建默认物化视图，90% 的查询仍会全扫 MV 全量数据。
物化视图必须显式分区，否则分区裁剪失效
基表按 sale_date RANGE 分区，但物化视图默认是单段表（non-partitioned），哪怕查询带 WHERE sale_date >= DATE '2026-01-01'，优化器也无分区可裁，只能全表扫描。
- 11g 不支持
CREATE MATERIALIZED VIEW ... PARTITION BY RANGE语法（该功能 12c+ 才引入），必须用ON PREBUILT TABLE方式绕过 - 先建已分区的普通表：
CREATE TABLE mv_sales_summary PARTITION BY RANGE (sale_date) (...)，分区定义（列类型、边界值）须与基表严格一致 - 再创建物化视图时绑定该表：
CREATE MATERIALIZED VIEW mv_sales_summary ON PREBUILT TABLE REFRESH FAST ON DEMAND AS SELECT ... - 验证是否生效：查
USER_TAB_PARTITIONS确认mv_sales_summary确实有多个分区，且PARTITIONING_TYPE = 'RANGE'
快速刷新失败常因物化视图日志漏列，而非语句复杂
报错 ORA-12052: cannot fast refresh materialized view 或静默退化为 COMPLETE 刷新，大概率不是 SQL 写得复杂，而是基表的物化视图日志没配全。
- 日志必须包含：所有 SELECT 列 +
ROWID+ 基表主键（或唯一约束列）+ 分区键列（如sale_date） - 执行：
CREATE MATERIALIZED VIEW LOG ON sales WITH PRIMARY KEY, ROWID, SEQUENCE (sale_date, customer_id, amount) INCLUDING NEW VALUES;—— 注意SEQUENCE后必须显式列出 MV 查询中用到的所有列 - 若基表分区键是函数表达式（如
TRUNC(sale_date, 'MM')），日志里也得加该表达式列：ADD COLUMN (TRUNC(sale_date, 'MM')) - 检查日志状态：
SELECT LOGGING, ROWIDS, PRIMARY_KEY FROM USER_MVIEW_LOGS WHERE MASTER = 'SALES';，确保三者均为YES
查询重写不触发，关键在 QUERY_REWRITE_INTEGRITY 和谓词匹配
即使物化视图状态为 VALID、ENABLE QUERY REWRITE 已启用，查询仍走基表，常见于 QUERY_REWRITE_INTEGRITY = ENFORCED（默认值之一）且 MV 数据被标为 stale。
- 必须在会话级或系统级设：
ALTER SYSTEM SET query_rewrite_integrity = STALE_TOLERATED;（注意不是FORCE，它不解决 stale 判定） - MV 定义中避免对分区键做函数包装：允许
SELECT sale_date, SUM(amount) ... GROUP BY sale_date；禁止SELECT TRUNC(sale_date, 'MM') AS month_key ... GROUP BY month_key，否则查询谓词无法映射 - 验证重写是否可能：
EXEC DBMS_MVIEW.EXPLAIN_MVIEW('mv_sales_summary');，重点看QSMQT_UNREWRITE是否出现，若有，说明语义断层存在 - 强制测试重写：
SELECT /*+ REWRITE(mv_sales_summary) */ COUNT(*) FROM sales WHERE sale_date >= DATE '2026-01-01';，再看执行计划是否命中 MV 分区
索引和统计信息必须手动同步，否则优化器“瞎猜”
物化视图是物理表，但 Oracle 不自动为其建索引、也不自动收集统计信息。没有本地索引 + 过期统计，即使分区存在，CBO 也可能因基数误估放弃分区裁剪。
- 在分区键和高选择性过滤列上建本地索引：
CREATE INDEX idx_mv_sale_cust ON mv_sales_summary (customer_id, sale_date) LOCAL; - 刷新后立即收集统计：
DBMS_STATS.GATHER_TABLE_STATS(ownname => 'SCHEMA', tabname => 'MV_SALES_SUMMARY', granularity => 'ALL');——granularity => 'ALL'强制采集每个分区的统计，不能省略 - 对比时间戳：
SELECT TABLE_NAME, LAST_ANALYZED FROM USER_TAB_STATISTICS WHERE TABLE_NAME IN ('SALES', 'MV_SALES_SUMMARY');，两者相差超过 1 天就应重收集 - 避免在物化视图上建低选择性索引（如
status_flag只有 Y/N），这类索引反而拖慢 DML 和查询
11g 的限制很实在：没有原生 MV 分区语法、快速刷新依赖日志列完整性、查询重写对谓词匹配极度敏感。最容易被忽略的是——物化视图分区结构和统计信息必须手动对齐基表，且每次刷新后都要重新收集，否则前面所有配置都白搭。
