核心信号是执行计划中出现PARTITION RANGE ALL或MATERIALIZED VIEW REWRITE；未出现则说明未裁剪或未重写，需检查QUERY_REWRITE_ENABLED设置、权限、物化视图BUILD IMMEDIATE和ENABLE QUERY REWRITE属性，以及查询谓词是否支持分区裁剪。
直接看执行计划里有没有 partition range all 或 materialized view rewrite，这是物化视图 + 分区表组合下性能是否被“裁剪”的核心信号。没裁剪就等于全扫，再快的硬件也扛不住。
怎么确认物化视图是否被实际重写（rewrite）
Oracle 不一定每次都会用物化视图，尤其当查询条件不满足 rewrite 条件时，它会默默退回到基表扫描。
- 必须开启重写开关：
ALTER SESSION SET QUERY_REWRITE_ENABLED = TRUE;，且用户要有QUERY REWRITE权限 - 物化视图本身要
BUILD IMMEDIATE且ENABLE QUERY REWRITE（建的时候漏掉这个，EXPLAIN PLAN永远看不到MATERIALIZED VIEW REWRITE） - 执行
EXPLAIN PLAN FOR SELECT ...后，查DBMS_XPLAN.DISPLAY，重点找Operation列是否出现MATERIALIZED VIEW REWRITE；如果看到的是TABLE ACCESS FULL对应基表名（比如T1），说明没走 rewrite - 加 hint 强制测试：
SELECT /*+ REWRITE(mv_name) */ ...，能跑通且 plan 显示该 mv 名称，说明 rewrite 路径可用
分区裁剪在物化视图里还生效吗
生效，但依赖两层裁剪：先裁物化视图自身分区（如果它也是分区的），再裁底层基表分区。任意一层没裁，就会放大 I/O。
- 物化视图如果是范围分区（如按
log_date），而查询WHERE log_date >= DATE '2025-01-01'，执行计划中应出现PARTITION RANGE ITERATOR或SINGLE，而不是ALL - 如果物化视图是基于分区表构建的（比如基表
sales_part按月分区），但物化视图自己没分区，那它的数据是“扁平”存的——此时分区裁剪只发生在基表刷新阶段，查询时已无分区概念 - 常见坑：物化视图定义里用了
TRUNC(SYSDATE)、SYSDATE - 7这类运行时才确定的值，优化器无法静态推导分区边界，容易导致PARTITION RANGE ALL
执行计划里看到 PARTITION RANGE ALL 怎么办
这不是物化视图专属问题，但和它叠加后更隐蔽：你以为走了 mv，其实底层还在扫所有分区。
- 先确认是不是真在扫分区表：查
Operation对应的Name列，如果是基表名（如SALES_PART），且Partition Start/End显示KEY或ROW LOCATION，说明分区键值在运行时才决定，但没被谓词约束住 - 检查 WHERE 条件是否“干净”：避免对分区键列使用函数，比如
WHERE TO_CHAR(part_col, 'YYYYMM') = '202503'会禁用裁剪；改用WHERE part_col >= DATE '2025-03-01' AND part_col - 物化视图刷新方式影响统计信息：如果用
ON DEMAND+DBMS_MVIEW.REFRESH，记得刷新后手动收集统计信息：DBMS_STATS.GATHER_TABLE_STATS，否则优化器可能误判分区数据分布 - 强制绑定分区键：在查询中显式写出分区键范围，哪怕它看起来“冗余”，比如物化视图已按
dt分区，查询仍加上AND dt BETWEEN ... AND ...
最易被忽略的一点：物化视图的分区字段和基表的分区字段不一致时，裁剪逻辑不会跨层传递。比如基表按 CREATE_TIME 分区，物化视图却按 REPORT_DATE 分区，那查询里只过滤 REPORT_DATE，对基表分区毫无作用——执行计划里照样 PARTITION RANGE ALL。
