RESULT_CACHE提示仅是缓存申请，实际生效需同时满足：表无触发器/物化视图日志、不含非确定性函数（如SYSDATE）、无序列/ROWNUM、非临时表或SYS/SYSTEM对象，且参数类型精度严格匹配。
SQL 里加 /*+ RESULT_CACHE */ 提示，不等于就缓存了
oracle 的 result_cache 提示只是“申请缓存”，是否真正进缓存，取决于底层限制是否全部满足。常见失败现象：执行计划里看到 result cache 操作符，但第二次查询的 consistent gets 没降、physical reads 还在，甚至 v$result_cache_objects 里压根没条目。
必须同时满足以下条件：
- 查询涉及的所有表不能有触发器、物化视图日志，也不能是
GLOBAL TEMPORARY TABLE或SYS/SYSTEM下的对象 - SQL 中不能出现任何非确定性函数：
SYSDATE、CURRENT_DATE、USER、DBMS_RANDOM.VALUE、SYS_GUID、SYSTIMESTAMP等 - 不能含序列（
seq.NEXTVAL）、ROWNUM、LEVEL、CONNECT BY等破坏结果稳定性的结构 - 若查远程数据库（
@dblink），需确认result_cache_remote_expiration非零，否则默认不缓
建议先用 EXPLAIN PLAN FOR SELECT /*+ RESULT_CACHE */ ... 查执行计划，再实际跑两次，立刻查 V$RESULT_CACHE_OBJECTS 和 V$SQL 中对应 SQL 的 EXECUTIONS 字段——第二次调用后 EXECUTIONS 只增 1，才说明缓存生效。
.NET 应用里传参要严防隐式类型转换
Oracle 的 RESULT_CACHE 缓存键是按参数值的字节级表示生成的，.NET 侧一个微小的类型声明差异，就会导致缓存分裂甚至报错。
典型问题场景：
- SQL 定义为
WHERE id = :p_id，而 .NET 用OracleParameter("p_id", OracleDbType.Int32)传123，和用OracleDbType.Varchar2传"123"，会被视为两个完全不同的缓存项 - 函数参数是
NUMBER(10,0)，但 .NET 传的是decimal（精度未显式控制），可能被 Oracle 解析为NUMBER(10,2)，键不匹配 - 使用 Dapper 或 Entity Framework Core 时，若未显式指定
DbType或OracleDbType，框架可能自动推导为Varchar2，而 SQL 期望NUMBER，直接触发ORA-06553: PLS-306
实操建议：
- 在 .NET 代码中统一用
OracleParameter显式声明类型与精度，例如：new OracleParameter("p_id", OracleDbType.Int32) { Value = 123 } - 避免用字符串拼接参数；所有绑定变量都走参数化
- 对关键高频查询，在应用启动时用固定参数预热一次，再查
V$RESULT_CACHE_OBJECTS确认状态为'Published'
缓存失效比想象中更激进，别高估它的稳定性
只要 SQL 查询所依赖的任意一张基表发生 DML（哪怕只是另一会话插入一行），整个缓存项立刻标记为 Invalid，下次调用必重算。这不是延迟失效，是即时、全量、不可绕过的。
这意味着：
- 查多张表的 SQL（如
JOIN config_table, status_code），只要其中一张表被更新，全部缓存清空 - 高并发写入配置表的系统，
RESULT_CACHE命中率可能长期低于 5%，此时它反而增加哈希计算开销 - 即使表只读，也要确认没被 DBA 或其他程序意外执行过
TRUNCATE或UPDATE—— 这些操作一样触发失效
验证方法：在第一次查询后记录 V$RESULT_CACHE_OBJECTS 中的 ID 和 STATUS；然后在另一会话对任一基表做 INSERT；再回来查该 ID，STATUS 通常已变 'Invalid'。
别忽略 result_cache_mode 参数的实际影响
数据库级参数 result_cache_mode 控制默认行为，但它只提供基础开关，不是“开了就能缓”的保障。
三种取值的实际效果：
-
MANUAL（默认）：必须显式加/*+ RESULT_CACHE */，否则不缓；但加了也不保证成功（仍受前述限制约束） -
FORCE：所有符合条件的查询自动缓，但依然跳过含非确定性函数、临时表等的语句；且/*+ NO_RESULT_CACHE */可覆盖它 -
OFF（即result_cache_max_size=0）：整个特性关闭，提示无效，视图返回空
检查当前设置：
SELECT name, value FROM v$parameter WHERE name = 'result_cache_mode';
注意：FORCE 模式下，如果某条 SQL 因违反限制被跳过，Oracle 不报错也不警告，只是静默不缓——所以不能靠参数开没开来判断缓存是否起效，必须看运行时行为。
真正能稳住缓存命中率的，只有两类场景：背后查的是几乎不变更的码表（如 COUNTRY_CODES）、或纯计算型 PL/SQL 函数（不含 SQL）。其余情况，尤其涉及业务主表或频繁更新的配置表，缓存大概率是“看着很美，用着很短”。
