Oracle 19c 物化视图与结果集缓存：为何完全不兼容？
先给出核心结论：在 Oracle 19c 中，物化视图本身既不会参与，也不会触发服务器端的结果集缓存（result_cache）。这并非权限配置遗漏或参数设置错误，而是两者底层的运行逻辑存在根本性的冲突，导致天然无法协同工作。
要深入理解这个问题，首先需要明确各自的功能定位。物化视图是一套完整的体系，包括预计算、物理存储以及增量刷新，它属于查询重写层面的对象。而结果集缓存则是在运行时于内存中生成快照，并依赖自动失效机制来管理缓存有效性。两者解决的问题层级不同，执行路径也截然不同，因此天然互不兼容。
下面从三个关键维度来剖析这一机制。
物化视图查询为何绕过 RESULT_CACHE
当执行 SELECT * FROM mv_name 时，Oracle 内部的实际处理流程如下：
- 解析阶段，系统识别出是对物化视图基表或日志的访问，或者直接读取物化视图的存储段（执行计划中表现为
TABLE ACCESS FULL或MATERIALIZED VIEW ACCESS）。 - 整个过程中，SQL 查询结果缓存的“候选判断”流程根本不会被触发。换言之，系统不会检查
result_cache_mode参数，也不会走V$RESULT_CACHE_OBJECTS的注册逻辑。 - 即便在查询语句中强行添加
/*+ RESULT_CACHE */提示，优化器也会直接忽略。原因在于：对物化视图的访问属于“对象级访问”，并不属于标准 SQL 执行计划中可被缓存的查询块。
RESULT_CACHE 对物化视图依赖对象无效
可以前往 V$RESULT_CACHE_DEPENDENCY 视图进行验证。该视图记录的依赖关系仅包含普通表、视图、同义词等对象的 OBJECT_ID，而物化视图本身并不在其中。这意味着：
- 当物化视图被刷新（执行
REFRESH）时，不会触发依赖它的缓存条目失效——因为缓存机制根本不知道物化视图的存在。 - 反过来，如果某个查询依赖的是普通表
T，而T恰好是某个物化视图的基表，那么T上发生 DML 操作时，仍然会导致该查询的缓存失效。但这个失效仅与基础表有关，与物化视图本身毫无关联。 - 在
V$RESULT_CACHE_DEPENDENCY中，永远看不到DEPEND_TYPE = 1指向物化视图的记录。
FORCE 模式下物化视图查询仍不缓存
有人可能会尝试将 result_cache_mode 设置为 FORCE，期望强制缓存生效。但答案依然无效。原因在于 FORCE 模式只对“可缓存的独立 SQL 查询”起作用，而物化视图的访问被明确归类为“对象访问操作”——就像直接读取一张表一样，根本不在缓存判定的范围之内。
可以通过一个简单测试来验证：执行 SELECT /*+ RESULT_CACHE */ COUNT(*) FROM mv_name，执行计划中不会出现 RESULT CACHE 这一行，V$RESULT_CACHE_OBJECTS 中也查不到对应的条目。作为对比，执行同样的 SELECT /*+ RESULT_CACHE */ COUNT(*) FROM t（换成普通表），就能看到缓存命中以及 pin_count 上升的变化。
最后需要提醒一点副作用：物化视图的刷新动作本身（例如 DBMS_MVIEW.REFRESH）会触发大量底层表的 DML，从而间接导致已有的大量 RESULT_CACHE 条目被批量失效。但这纯粹是一个副产品式的副作用，绝非协同工作的机制。如果试图通过结果集缓存来加速物化视图的查询，那么从一开始思路就错了。
