物化视图本身不自动加速查询，真正起效的是查询重写（QUERY_REWRITE_ENABLED=TRUE且满足语义匹配、权限、索引、MV状态VALID等全部条件），否则EXPLAIN PLAN仍扫基表；必须用DBMS_MVIEW.EXPLAIN_REWRITE验证重写是否成功。
物化视图本身不提速，真正起作用的是查询重写（query rewrite）自动命中预计算结果——前提是执行计划里能看到对物化视图的访问，而不是扫基表。
为什么BI报表查得慢，建了MV却没效果？
常见现象是：报表SQL跑得慢，建完物化视图后EXPLAIN PLAN仍显示TABLE ACCESS FULL基表，MV_NAME完全没出现在执行计划里。
- 最常被忽略的是
QUERY_REWRITE_ENABLED = TRUE未开启，或者QUERY_REWRITE_INTEGRITY = STALE_TOLERATED（应设为TRUSTED） -
staleness字段为STALE或UNUSABLE：查SELECT mview_name, staleness FROM user_mviews确认状态 - 执行查询的用户缺少
QUERY REWRITE系统权限，即使DBA建了MV，普通用户查不到重写效果 - 基表刚做了大量DML但还没刷新MV，优化器会主动绕过重写以保证数据一致性
分区裁剪失效导致物化视图变“全表扫描”
BI报表常按时间维度筛选（如WHERE created_date >= DATE '2025-01-01'），若物化视图没对齐分区策略，性能优势直接归零。
- 执行计划中必须出现
pstart/pstop值，且类型应为PARTITION LIST SINGLE或ITERATOR，不是ALL - 物化视图定义中必须显式包含分区键列（如
created_date），不能只在WHERE里用，也不能用函数包裹（TRUNC(created_date)会阻断裁剪） - 基表有分区，但MV没建在相同分区策略上（比如基表按月分区，MV却是按年聚合+无分区），优化器无法推导裁剪边界
- 物化视图日志缺失分区键：建日志时需带
SEQUENCE(created_date)，否则FAST刷新和裁剪都可能失败
实时计算（ON QUERY COMPUTATION）启用失败的硬性条件
想让查询“秒出”最新数据（而非等刷新），必须满足全部限制，缺一不可——哪怕只漏一条，ORA-12015就立刻报错。
- 物化视图定义只能是单表投影：
SELECT col1, col2, created_date FROM sales✅；含JOIN、GROUP BY、SUM()、子查询、分析函数❌ - 基表必须有主键或唯一约束，且MV的SELECT列表必须包含全部主键列（不能只选部分）
- 刷新方式只能是
ON DEMAND或ON COMMIT；若建为REFRESH COMPLETE，实时计算自动禁用 - 隐含参数
_mv_refresh_use_query_computation必须为TRUE（默认开启，但某些2025年后的补丁版本可能关闭，需手动确认）
BI工具连接下容易踩的坑
很多BI工具（如Tableau、Power BI）默认加/*+ NO_QUERY_TRANSFORMATION */或强制走直连，会直接禁用重写。
- 检查生成的SQL是否含
NO_QUERY_TRANSFORMATION、NO_REWRITE等hint，BI配置里关掉“禁用优化器重写”类选项 - 避免在WHERE中用绑定变量做范围判断（如
:p_start_date），Oracle 12c对绑定变量的分区裁剪支持不稳定，改用字面量或SQL Profile固化执行计划 - 物化视图上必须建索引——尤其对BI常用筛选字段（如
region、product_category），否则即使重写成功，扫描MV本身也慢 - 跨库场景（DBLink）下，MV必须建在本地库，且源表日志要建在远程库；否则
FAST REFRESH会失败，QUERY REWRITE也可能被跳过
最关键的不是“建了MV”，而是每次修改BI SQL或基表结构后，都要重新验证EXPLAIN PLAN是否真走MV、pstart/pstop是否生效、staleness是否为OK——这些点任何一个松动，性能收益就归零。
