1. 版本支持

Oracle 11gR1 及以上（11.1.0.6+）支持 RESULT_CACHE 结果集缓存
10g 及更早版本不可用
Oracle版本检查方法（用于确认当前数据库版本是否支持）：

SELECT * FROM v$version WHERE banner LIKE 'Oracle%';

查询结果中包含“11.1.0.6”及以上版本号，即支持RESULT_CACHE功能；若显示10g及以下版本（如10.2.0.x），则不支持。

2. 默认是否开启

默认开启
检查是否开启：

show parameter result_cache_max_size;

值 > 0 = 已开启；= 0 则未开启

3. 手动开启方法（如未开启）

ALTER SYSTEM SET result_cache_max_size = 64M SCOPE=BOTH;

4. SQL 写法（含 WITH 子句）

/*+ RESULT_CACHE */ 加在最外层 SELECT 后面：

WITH t1 AS (SELECT ...), t2 AS (SELECT ...)
SELECT /*+ RESULT_CACHE */
  字段列表
FROM t1 JOIN t2 ...
WHERE ...

5. 缓存规则

• 不同查询条件和不同参数值 = 独立缓存
• 依赖的任意表发生 DML（insert/update/delete），缓存立即失效
• 无默认时间过期，靠 LRU 内存淘汰，不由时间控制

6. 查看缓存是否命中

SELECT name, value 
FROM v$result_cache_statistics 
WHERE name IN ('Create Count Success','Find Count');

• Create Count Success：成功缓存条数
• Find Count：缓存命中次数（>0 即生效）

  7. 适用与限制

• 适合：看板查询慢、数据不频繁变化、想加速重复查询
• 不适合：必须严格按几分钟缓存、无视数据变化的场景，如需固定周期缓存（如 5 分钟），建议用物化视图定时刷新或应用层缓存（Redis）

8、RESULT_CACHE 实际使用风险（精简版，只讲关键）

1. 缓存会莫名其妙失效（最常见坑）

只要 SQL 关联的任意一张表有 insert/update/delete/truncate，缓存立刻失效
看板刚缓存完，有人改下数据，下次又变慢
你控制不了缓存存活时间

2. 占 PGA/SGA 内存，可能导致数据库卡顿

缓存存在共享内存里，查询结果越大、条件越多，占内存越多
大量看板并发 + 大结果集 → 内存吃满
可能引发其他 SQL 变慢、内存争用

3. 相同 SQL 才命中，差一个空格都不行

换行、空格、大小写、注释不一样 → 新缓存
程序拼接 SQL 不规范 → 基本缓存不上
只有完全一模一样的 SQL 才会复用缓存

4. 含动态函数直接不缓存

SQL 里有 sysdate /systimestamp/sequence.nextval/ 自定义函数→ 缓存直接不生效，加了 hint 也白加

5. 高并发大看板可能缓存抖动

很多人同时点不同条件 → 大量创建缓存又很快失效→ 反而比不加 hint 更耗资源

6. 版本低（早期 11g）有 bug

内存泄漏
缓存死锁
结果错乱
生产上保守的 DBA 基本都会禁用它
最简单结论
你只是偶尔打开的看板：可以用，风险不大
你是高并发、大报表、实时数据、11g 早期版本：
不建议用 RESULT_CACHE，更稳的是：
物化视图（定时刷新）
应用层 Redis 缓存

（注：文档部分内容可能由 AI 生成）