@Cacheable 与 Oracle Result Cache 完全独立，无法直接结合使用；前者是 Spring 应用层方法级缓存，后者是 Oracle 数据库端 SQL 结果级缓存，二者无协议互通、无共享存储、无生命周期联动，混用易致数据不一致。
@cacheable 和 oracle result cache 是两套完全独立的缓存机制，不能直接结合使用。 你无法让 @cacheable 自动触发或复用 oracle 数据库层的 result cache，反之亦然。强行混用不仅不会叠加效果，反而容易引发数据一致性、缓存失效逻辑混乱等严重问题。
为什么 @Cacheable 无法利用 Oracle Result Cache
Oracle Result Cache 是数据库服务端的 SQL 结果级缓存，由 Oracle 实例管理，只对满足严格条件（如查询语句完全相同、绑定变量值一致、相关对象未被 DML 修改等）的 SELECT 语句自动生效；而 @Cacheable 是 Spring 应用层的方法级缓存，基于 Java 对象序列化/反序列化，缓存的是方法调用的完整返回值（比如一个 User 对象），与 SQL 执行过程完全隔离。
两者之间没有协议互通、没有共享存储、也没有生命周期联动 —— Spring 不知道 Oracle 缓存了什么，Oracle 也完全不感知 Spring 的 @Cacheable 注解。
- Oracle Result Cache 的命中与否，对 Spring 来说只是 JDBC 查询耗时变短了，
@Cacheable仍会按自己的 key 规则判断是否走应用缓存 - 如果同一张表在 Oracle 层被其他应用更新，Result Cache 会自动失效，但
@Cacheable完全无感知，仍可能返回脏数据 - 你在
@Cacheable中配置key="#id"，和 Oracle 对SELECT * FROM user WHERE id = ?做的 Result Cache，底层 key 构造、失效策略、作用域完全不同
实际项目中更合理的分层缓存策略
与其试图“结合”，不如明确各层职责，让它们协同而非耦合：
- Oracle Result Cache 适合：固定、低频变更、高并发读的轻量 SQL（如配置表、状态字典），且 DBA 已开启并调优过
RESULT_CACHE_MODE和内存分配 -
@Cacheable+ Caffeine/Redis 适合：业务逻辑封装后的结果（如组装了关联数据的 DTO）、需要自定义 key 或 condition 的场景（如unless="#result == null"）、需主动清理（@CacheEvict）的业务流 - 真正要提升性能，优先检查：SQL 是否可下推过滤、索引是否覆盖、是否误用了 N+1 查询 —— 这些比依赖任何缓存都更根本
@Cacheable 配置中容易忽略的关键点
如果你决定用 @Cacheable 替代部分 Oracle Result Cache 场景，请特别注意这些实操细节：
- 默认 key 生成器对复杂参数（如自定义对象、List）可能生成重复或不可靠的 key，务必显式写
key表达式，例如key="#user.id + '_' + #user.type" -
unless比condition更常用：比如unless="#result == null || #result.isDeleted()"，避免把空或无效结果塞进缓存 - 使用 Redis 作为
CacheManager时，必须配置序列化器（如GenericJackson2JsonRedisSerializer），否则@Cacheable可能静默失败或存入乱码 -
sync = true能防止缓存击穿（多个线程同时发现缓存 miss 后并发回源），但仅限单机部署；集群环境下需配合分布式锁，@Cacheable本身不解决
真正棘手的地方在于：当业务要求「强一致性」时，你得在 Oracle 层做 DML 后主动触发 @CacheEvict，或者反过来，在应用层更新后手动清 Oracle 的 Result Cache（通过 DBMS_RESULT_CACHE.FLUSH），这两者都需要额外的事务协调和错误兜底 —— 这已经超出 @Cacheable 的能力范围了。
