RESULT_CACHE函数必须显式声明且无副作用：需紧接RETURN后书写，禁止DML、非确定性函数及包级变量访问，参数值决定缓存键，失效由依赖表变更自动触发，受RESULT_CACHE_MODE和内存参数限制。
RESULT_CACHE函数必须声明且无副作用
Oracle 11g中，PL/SQL函数要进结果缓存，RESULT_CACHE不是可选修饰符，而是强制语法要求。它必须显式写在函数声明末尾，且函数体内部不能有任何破坏确定性的操作。
-
RESULT_CACHE子句必须紧接在RETURN类型之后，例如：FUNCTION get_config_value(p_key VARCHAR2) RETURN VARCHAR2 RESULT_CACHE - 禁止出现：
INSERT/UPDATE/DELETE、SELECT ... FOR UPDATE、调用SYSDATE/DBMS_RANDOM、读取包级变量或游标变量 - 允许的操作：纯查表（仅
SELECT）、字符串拼接、数值计算、调用其他带DETERMINISTIC或RESULT_CACHE的函数 - 若函数含DML但未报错，Oracle会静默退化为普通执行——缓存不生效，也不抛异常，极易误判
绑定变量值决定缓存键，不是函数名
同一个函数被不同参数调用，会生成独立缓存条目。Oracle把完整参数列表（包括值）作为缓存键，而非函数签名本身。
- 调用
get_customer_rating(1001)和get_customer_rating(1002)→ 两个缓存条目 - 参数类型必须严格匹配：传
NUMBERvsCHAR会被视为不同键，即使值相同 - NULL参数参与哈希计算：
get_config_value(NULL)与get_config_value('TIMEOUT')绝不共享缓存 - 避免在函数内做隐式类型转换（如
p_id + 0），可能干扰键一致性
缓存失效完全由Oracle自动触发，Java层无法干预
你写的函数一旦进缓存，其生命周期就脱离Java控制。失效只取决于数据库对象依赖关系，JDBC或Spring里任何操作都无效。
- 只要函数里
SELECT涉及的表（如config_table）被UPDATE/DELETE/INSERT，对应所有缓存条目立刻标记为INVALID - 依赖视图？那视图基表变更也会触发失效；依赖物化视图？则MV刷新即失效
-
DBMS_RESULT_CACHE.INVALIDATE可手动清空，但这是DBA级操作，应用代码调用需额外权限，且影响全局 - JDBC用
CallableStatement调用函数时，加setFetchSize或改事务隔离级别，对缓存命中率毫无影响
容易忽略的初始化参数和内存限制
就算函数写对了，RESULT_CACHE也可能根本没启用——它受实例级参数压制，且有硬性内存天花板。
-
RESULT_CACHE_MODE必须是MANUAL（默认）或FORCE；设为OFF则所有RESULT_CACHE声明都被忽略 -
RESULT_CACHE_MAX_SIZE默认仅占SGA的1%，若函数返回大结果集（如SELECT * FROM big_lookup_table），可能因超RESULT_CACHE_MAX_RESULT（默认5%）被直接拒绝缓存 - 查当前配置：
SHOW PARAMETER result_cache；看缓存使用情况：SELECT * FROM V$RESULT_CACHE_MEMORY - 开发环境常设
RESULT_CACHE_MAX_SIZE=32M测试，但上线前必须和DBA确认SGA余量，避免挤占Shared Pool
缓存键生成和失效逻辑是黑盒，但依赖表变更后缓存是否真的清掉，得靠V$RESULT_CACHE_OBJECTS里的STATUS列验证，不能只信“应该失效了”。
