result_cache与物化视图互斥，不可叠加使用；前者绕过查询重写直接缓存结果，后者依赖语义匹配和增量刷新，混用会导致结果不一致、缓存抖动及调优困难。
result_cache 和物化视图是两类完全独立的加速机制，不能叠加生效，也不应混用。oracle 19c 中，对同一查询同时启用两者，不仅不会提速，反而可能引入额外开销、缓存冲突甚至结果不一致。
RESULT_CACHE 会绕过物化视图的查询重写路径
当一个 SQL 加了 /<em>+ RESULT_CACHE </em>/ 提示或 RESULT_CACHE_MODE=FORCE 生效时，Oracle 直接跳过优化器的查询重写（query rewrite）阶段——也就是说，即使你已建好 sales_mv 并启用了 ENABLE QUERY REWRITE，只要用了 result cache，优化器就不再尝试匹配物化视图，而是把整个查询结果塞进共享池的 result cache 区域。
- 常见错误现象：EXPLAIN PLAN 显示走基表（或物化视图本身），但实际执行路径却是 result cache lookup；DBMS_MVIEW.EXPLAIN_REWRITE 返回
UNREWRITTEN，不是因为物化视图没配好，而是因为 result cache 已“劫持”了执行流程。 - 本质原因：
RESULT_CACHE是语句级缓存，基于 SQL 文本 + 绑定变量哈希；物化视图重写是语义级匹配，依赖列映射、谓词下推和完整性约束。二者触发时机、判断逻辑、内存区域互不兼容。
物化视图刷新与 RESULT_CACHE 失效机制存在根本冲突
物化视图靠 MLOG$_xxx 日志 + SNAPTIME$$ 控制增量刷新节奏；而 RESULT_CACHE 的失效依赖 V$RESULT_CACHE_DEPENDENCY 中记录的 DEPEND_ID 对象变更。
- 若物化视图底层基表发生 DML，
RESULT_CACHE会立即失效对应缓存项（只要该表在依赖列表中）；但物化视图自身尚未刷新，此时若查询走 result cache，返回的是旧数据；若走物化视图，则可能是新数据（取决于刷新状态）——同一业务查询在不同时间点可能返回不一致结果。 - 更麻烦的是：物化视图刷新本身（如
DBMS_MVIEW.REFRESH）会触发基表变更通知，连带清空所有依赖该基表的 result cache 条目，导致缓存命中率骤降，反而放大抖动。
选哪个？看场景，别堆叠
- 用物化视图：适合聚合计算重、连接复杂、基表更新频次低（如每天批量 ETL 后刷新）、需要长期稳定副本的场景（报表、BI 取数）。它提供物理数据隔离，支持索引、分区、统计信息，且可被多个查询共享重写。
- 用
RESULT_CACHE：适合单条高频、轻量、无绑定变量或变量组合有限、结果集小（RESULT_CACHE_MAX_RESULT默认仅占总缓存 5%）、且基表几乎只读的查询（如配置表查询、静态码表联查）。它免刷新、免维护，但无法加速含序列、SYS_CONTEXT、SYSDATE等非确定性函数的语句。 - 不推荐混合：比如在物化视图定义里加
/<em>+ RESULT_CACHE </em>/，或对查询物化视图的 SQL 再加该提示——既浪费内存，又破坏物化视图的统计信息有效性，还让 DBA 难以定位慢查询根源。
真正容易被忽略的点是：RESULT_CACHE 的内存区域（shared pool 子区）和物化视图存储段（user tablespace）不在同一资源池里，监控和调优必须分开做。查 V$RESULT_CACHE_STATISTICS 看命中率，查 DBA_MVIEWS 和 DBA_MVIEW_LOGS 看刷新延迟，二者指标不可交叉解读。
