Oracle 19c中物化视图不支持RESULT_CACHE,因其访问属于对象级操作而非标准SQL查询,绕过缓存判定流程,即使加提示或设FORCE模式也无效,且依赖关系不被V$RESULT_CACHE_DEPENDENCY记录。
oracle 19c 中物化视图(materialized view)本身不参与、也不触发服务器端结果集缓存(result_cache),这不是配置错误或权限问题,而是由两者底层机制根本冲突导致的。
物化视图和结果集缓存解决的是不同层级的问题:前者是预计算+物理存储+增量刷新的查询重写对象;后者是运行时内存快照+依赖自动失效的轻量级缓存。它们在 Oracle 内部走完全不同的执行路径,互不兼容。
当你执行 SELECT * FROM mv_name,Oracle 实际做的是:
TABLE ACCESS FULL 或 MATERIALIZED VIEW ACCESS)result_cache_mode、不走 V$RESULT_CACHE_OBJECTS 的注册逻辑)/*+ RESULT_CACHE */ 提示,优化器也会忽略它——因为物化视图访问属于“对象级访问”,不是标准 SQL 执行计划中的可缓存查询块V$RESULT_CACHE_DEPENDENCY 只记录普通表、视图、同义词等对象的 OBJECT_ID 依赖关系,但不包含物化视图本身。
REFRESH)时,不会触发依赖它的缓存条目失效(因为缓存压根不知道它存在)T,而 T 是某个物化视图的基表,那么 T 的 DML 仍会失效该查询的缓存——但这个失效跟物化视图无关,只跟基础表有关V$RESULT_CACHE_DEPENDENCY 永远看不到 DEPEND_TYPE = 1 指向物化视图的记录即使把 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 条目——但这是副作用,不是协同机制。想靠结果缓存加速物化视图查询,本质上走错了方向。