oracle 19c中物化视图不支持result_cache，因其访问属于对象级操作而非标准sql查询，绕过缓存判定流程，即使加提示或设force模式也无效，且依赖关系不被v$result_cache_dependency记录。
oracle 19c 中物化视图（materialized view）本身不参与、也不触发服务器端结果集缓存（result_cache），这不是配置错误或权限问题，而是由两者底层机制根本冲突导致的。
物化视图和结果集缓存解决的是不同层级的问题：前者是预计算+物理存储+增量刷新的查询重写对象；后者是运行时内存快照+依赖自动失效的轻量级缓存。它们在 Oracle 内部走完全不同的执行路径，互不兼容。
物化视图查询为什么绕过 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 条目——但这是副作用，不是协同机制。想靠结果缓存加速物化视图查询，本质上走错了方向。
