为什么Oracle 19c物化视图无法利用结果集缓存 Result Cache

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 条目被批量失效。但这只是副产品式的副作用，并非协同工作机制。试图通过结果集缓存加速物化视图查询，在思路上本身就走错了方向。