物化视图未走分区裁剪主因是未继承基表分区结构，需显式指定partition by range；快速刷新失败多因日志缺失关键列；索引应建在分区键和高选择性过滤列上；统计信息必须刷新后及时收集，否则优化器误判执行计划。
物化视图没走分区裁剪，查询还是全扫
oracle 分区表上建的物化视图，如果查询条件带了分区键但依然慢，大概率是物化视图本身没继承原表的分区结构，导致优化器无法做分区裁剪。物化视图默认不自动分区，哪怕基表是按 order_date 范围分区，物化视图仍是单个段（segment），查任意时间范围都得扫全量数据。
解决方法是显式指定物化视图分区策略，和基表对齐：
- 建物化视图时加
ON PREBUILT TABLE+ 手动创建已分区的容器表，再关联物化视图 - 或直接用
CREATE MATERIALIZED VIEW ... PARTITION BY RANGE(...)（12c 及以上支持） - 确认分区键类型、粒度、边界值与基表严格一致，否则即使语法通过，运行时也可能降级为全扫描
物化视图日志缺失或字段不全，导致快速刷新失败
一旦物化视图启用快速刷新（REFRESH FAST ON COMMIT），就必须有对应物化视图日志，且日志必须包含所有 SELECT 列（含 ROWID）、分区键列、以及参与 JOIN 的连接列。漏掉任意一个，Oracle 就会退回到完全刷新，而完全刷新会锁表、重建整个物化视图，查询自然卡住。
检查要点：
- 执行
SELECT * FROM USER_MVIEW_LOGS WHERE MASTER = 'YOUR_BASE_TABLE'，确认日志存在且LOGGING为 YES - 日志里必须含
ROWID、SEQUENCE、INCLUDING NEW VALUES，且ADD COLUMN补全所有物化视图 SELECT 中的列 - 若基表有分区键（如
TRUNC(SALES_DATE, 'MM')），日志里也得加这个表达式列，不能只靠原列
物化视图索引建在错误列上，反而拖慢查询
给物化视图建索引不是越多越好。如果索引列和查询谓词不匹配，或者索引列选择性极低（比如只有 Y/N 值的标志位），Oracle 可能放弃索引走全表扫描；更糟的是，如果物化视图本身数据量不大（比如几万行），索引维护开销反而高于扫描收益。
实操建议：
- 优先在物化视图的分区键（如
SALES_MONTH）和常用过滤列（如CUSTOMER_ID）组合上建本地索引：CREATE INDEX idx_mv_cust_month ON mv_sales(CUSTOMER_ID, SALES_MONTH) LOCAL - 避免在
SYSDATE - CREATED_DATE这类动态计算列上建索引——物化视图数据是快照，这类列无意义 - 用
EXPLAIN PLAN FOR看执行计划，确认索引是否被真正使用；如果ACCESS PREDICATES为空，说明索引未生效
物化视图统计信息过期，优化器选错执行路径
物化视图不是基表，它的统计信息不会随基表自动更新。如果物化视图刷新后没及时收集统计信息，优化器仍按旧数据量估算（比如以为只有 1000 行，实际已到 500 万），就可能选错连接顺序、忽略索引、甚至走嵌套循环而非哈希连接。
关键动作：
- 每次完全刷新或大批量快速刷新后，立即执行：
DBMS_STATS.GATHER_TABLE_STATS(ownname => 'SCHEMA_NAME', tabname => 'MV_NAME') - 不要依赖
ESTIMATE_PERCENT => DBMS_STATS.AUTO_SAMPLE_SIZE—— 对物化视图，明确设为100更稳妥，尤其当数据分布倾斜时 - 检查
LAST_ANALYZED字段：SELECT TABLE_NAME, LAST_ANALYZED FROM USER_TABLES WHERE TABLE_NAME = 'MV_NAME'
分区裁剪失效、快速刷新退化、索引建了不用、统计信息滞后——这四点只要中一个，物化视图就会从加速器变成拖油瓶。最常被跳过的其实是统计信息更新，因为没人盯着物化视图的 LAST_ANALYZED 时间戳。
