oracle物化视图本身不参与分区裁剪，裁剪是否生效取决于查询语句中是否对物化视图的分区键列使用可静态推导的where条件，如直接比较、避免函数包裹、确定性值及外层过滤等。
oracle物化视图本身不参与分区裁剪——失效根源不在视图，而在查询语句如何引用它。 物化视图是预计算的物理表，一旦创建完成，其数据存储与普通表无异；真正决定分区裁剪是否生效的，是 select 语句中对物化视图（或其基表）的 where 条件写法，以及该语句是否能被优化器静态推导出分区范围。
WHERE 条件必须直接作用于物化视图的分区键列
即使物化视图底层基于分区表构建，若查询时没在 WHERE 子句中显式约束其分区键，优化器无法下推过滤，就会全分区扫描。
- ✅ 有效：
SELECT * FROM mv_sales_summary WHERE dt = '2024-03-01'（dt是物化视图的分区列，且类型为DATE） - ❌ 失效：
SELECT * FROM mv_sales_summary WHERE TO_CHAR(dt, 'YYYYMMDD') = '20240301'（TO_CHAR包裹破坏静态可推导性） - ❌ 失效：
SELECT * FROM mv_sales_summary WHERE dt >= SYSDATE - 7（SYSDATE是非确定性函数，值在运行时才知） - ❌ 失效：
SELECT * FROM mv_sales_summary WHERE dt IN (SELECT MAX(dt) FROM dim_date)（子查询结果不可静态确认，多数 Oracle 版本放弃裁剪）
JOIN 场景下分区键不能藏在 ON 或子查询里
物化视图常被用作汇总层，和明细表 JOIN。此时分区裁剪极易丢失，关键看过滤条件落在哪一层。
- ✅ 有效：
SELECT /*+ USE_NL(mv) */ m.prod_id, v.total_amt FROM sales_detail d JOIN mv_sales_summary v ON d.dt = v.dt WHERE v.dt = '2024-03-01'（外层WHERE直接限定物化视图分区键） - ❌ 失效：
SELECT ... FROM sales_detail d JOIN mv_sales_summary v ON d.dt = v.dt AND v.dt = '2024-03-01'（ON中的条件不触发物化视图自身的分区裁剪，仅影响连接逻辑） - ❌ 失效：
WHERE v.dt IN (SELECT dt FROM calendar WHERE is_workday = 'Y')（即使calendar表很小，该IN子查询仍导致优化器放弃静态分区推导）
物化视图定义里的 SELECT 不影响查询时的裁剪行为
很多人误以为“物化视图建的时候用了分区表，查它就自动裁剪”。其实物化视图定义中的 SELECT 只决定它存什么数据，不决定你怎么查它。查它的 SQL 才是裁剪开关。
- 物化视图定义含
GROUP BY dt，不代表你查它时省略WHERE dt = ...就能裁剪 - 物化视图刷新方式（
FAST/COMPLETE）和刷新状态（STALE/FRESH）只影响数据新旧，不影响执行计划中是否读分区 - 若物化视图基于非分区表构建，那它根本不存在“分区裁剪”概念——哪怕源表是分区的，MV 本身已脱离分区结构
最容易被忽略的一点：Oracle 对物化视图的统计信息收集默认不包含分区级粒度。即使写了正确的 WHERE dt = ...，若 DBA_TAB_PARTITIONS 中对应分区的 NUM_ROWS 为 NULL 或严重失真，优化器可能因成本估算偏差而放弃裁剪路径。务必确认 EXEC DBMS_STATS.GATHER_TABLE_STATS(..., GRANULARITY => 'PARTITION') 已执行到位。
