物化视图查询慢的主因是未走分区裁剪或未启用实时计算：需检查执行计划有无pstart/pstop、是否含分区键列、WHERE条件是否直接引用MV列；实时计算要求单表投影、基表有主键、刷新方式为ON DEMAND/COMMIT且参数_mview_refresh_use_query_computation=TRUE；还需确保QUERY_REWRITE_ENABLED=TRUE、MV状态VALID、权限充足及MV与基表分区策略一致。
物化视图本身不慢，慢的是查询没走分区裁剪（partition pruning）或没用上实时计算（on query computation）——尤其在基表已分区但物化视图未对齐时。
物化视图查询没走分区裁剪的典型表现
执行计划里看不到 pstart / pstop，或者显示 pstart=1 pstop=4 却只查某几个分区的数据；EXPLAIN PLAN 中扫描类型是 TABLE ACCESS FULL 而非 PARTITION LIST SINGLE 或 ITERATOR。
- 检查物化视图定义是否包含分区键：如果基表按
CREATED_DATE分区，但物化视图 SELECT 列里没包含该字段，优化器无法推导裁剪条件 - WHERE 条件必须直接引用物化视图中**实际存在的列**，不能依赖函数转换（如
TRUNC(CREATED_DATE)会阻断裁剪） - 确保物化视图日志存在且含分区键列：
CREATE MATERIALIZED VIEW LOG ON t1 WITH ROWID, SEQUENCE(created_date) INCLUDING NEW VALUES;
实时物化视图（ON QUERY COMPUTATION）启用失败的常见原因
明明加了 ON QUERY COMPUTATION，查询却仍报 ORA-12015: cannot create a fast refresh materialized view from a complex query 或返回陈旧数据。
- 物化视图定义中不能含聚合、连接、子查询——实时计算只支持简单单表投影（
SELECT col1, col2 FROM base_table） - 基表必须有主键或唯一约束，且物化视图 SELECT 列需覆盖全部主键列
- 刷新方式只能是
ON DEMAND或ON COMMIT不可用；若设为REFRESH COMPLETE，实时计算自动失效 - 查询时需确保
_mv_refresh_use_query_computation隐含参数为TRUE（默认开启，但某些补丁版本可能关闭）
执行计划里物化视图被绕过（query rewrite 禁用）
即使建了物化视图，EXPLAIN PLAN 显示还是扫基表，不是扫 MV_NAME。
- 确认
QUERY_REWRITE_ENABLED = TRUE且QUERY_REWRITE_INTEGRITY = TRUSTED（后者要求物化视图约束与基表严格一致） - 物化视图状态必须是
VALID：SELECT mview_name, staleness FROM user_mviews;中不能是STALE或UNUSABLE - 如果基表刚 DML 过，但物化视图还没刷新，
staleness=STALE时即使开了实时计算，重写也可能被跳过——此时应手动EXEC DBMS_MVIEW.REFRESH('MV_NAME'); - 注意权限：执行查询的用户需有
QUERY REWRITE系统权限，或在物化视图所在 schema 上有该对象权限
最易被忽略的一点：物化视图的分区策略和基表不一致时，ON QUERY COMPUTATION 会静默失效——哪怕语法通过，执行计划里也看不到实时计算的影子。务必用 DBA_PART_TABLES 对比两边的 partitioning_type 和 partition_count。
