为啥10g的结果不进缓存

Question

你的参数是不是 没有用绑定变量，而是用硬编码的方式啊？
show  parameter cursor_sharing  看看两个数据库的是不是一样？

Answer 1

和缓存应该没有关系
虽说result cache是11g的新特性，但默认情况下并不启用，从执行计划中也可以看出这点两个查询的统计信息中，一致读差距很大，检查两个数据库中表的数据量的对比，以及占用块数的对比(从user_segments中查看)另外，执行计划中采用了hash join，我不太清楚这里的涉及到的字段的值的分别情况和选择性，这里可能有可以优化的空间

Answer 2

感谢您的回复，这条语句我是从一个函数里拿出来的，自己替换变量形成的测试数据。函数的话是不是都是绑定变量啊？
这两个库的cursor_sharing都是EXACT

Answer 3

感谢您的回复，两个库的数据就差几天的，数据量差别不太大。
10g下查询的结果：
SQL> select SEGMENT_NAME,BYTES,BLOCKS from user_segments where SEGMENT_NAME='JMJKDA';SEGMENT_NAME                                                                           BYTES     BLOCKS
--------------------------------------------------------------------------------- ---------- ----------
JMJKDA                                                                            2130706432     26009611g下查询的结果：
SQL> select SEGMENT_NAME,BYTES,BLOCKS from user_segments where SEGMENT_NAME='JMJKDA';SEGMENT_NAME                                                                           BYTES     BLOCKS
--------------------------------------------------------------------------------- ---------- ----------
JMJKDA                                                                            2147483648     262144另外11g的parameter
SQL> show parameter resultNAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
client_result_cache_lag              big integer 3000
client_result_cache_size             big integer 0
result_cache_max_result              integer     5
result_cache_max_size                big integer 16M
result_cache_mode                    string      MANUAL
result_cache_remote_expiration       integer     0说实话加入是因为这个新特性我就不纠结了...

Answer 4

10g的这边的统计信息没有问题
11g的一致读这么小有点奇怪。不是因为结果缓存的事，result_cache_mode为manual，查询时要加hint才会生效可以在11g这边的语句做个10046看看