BUFFER CACHE的命中率已成为一个老生常谈的话题，在数据库等待事件出现之前，DBA进行数据库系统级优化时，往往会首先观察BUFFER CACHE的命中率。命中率高就意味着数据库运行正常，很多Oracle官方提供的巡检脚本都将BUFFER CACHE的命中率大于90%作为考核数据库性能的指标之一。
BUFFER CACHE命中率高意味着Oracle服务进程基本上都能从BUFFER CACHE中获取相应的数据块。如果不考虑存储的CACHE因素，仅从数据块的读取效率上来讲，从BUFFER CACHE中读取（纳秒级）要比直接从磁盘上读取（毫秒级）高很多。所以运行效率高的数据库往往BUFFER CACHE命中率也较高。但需要强调的是，仅通过一项指标就判断数据库BUFFER CACHE正常，未免显得太过绝对，比如，来考虑一下如下场景：
大表全表扫描时。如果大表的数据块没有在BUFFER CACHE中，那么对大表进行全表扫描时，会引起大量的物理读（表现为db file scattered read等待事件），进而会导致BUFFER CACHE命中率下降。这种场景多见于数据库仓库系统，在这类系统中，BUFFER CACHE的命中率尽管很低，但其业务性质决定了不得不全表扫描。
执行计划出错时。考虑如下相对极端的场景：2张大表，它们所占的数据块全部在BUFFER CACHE中。它们等值连接时走的是全表扫描并且采用的是NESTED LOOP JOIN的执行计划。由于2张表的数据块全部在BUFFER CACHE中，所以在取值过程中BUFFER CACHE的命中率为100%，但事实上其执行效率却是很低的。这是最常见的一种情况。
“热”块争用时。这里的“热”块指的是多个进程同时访问BUFFER CACHE中的数据块。“热”块肯定位于BUFFER CACHE中，所以访问“热”块时BUFFER CACHE命中率肯定是100%。但多个进程访问“热”块时往往出现LATCH:CACHE BUFFERS CHAINS等相关等待事件，数据库的性能会因为这些等待事件而变得缓慢。
从以上3个场景可以看出，BUFFER CACHE命中率的高低和数据库的性能没有必然和绝对的关系。但一般情况下，还是希望BUFFER CACHE命中率指标越高越好，AWR/STATSPACK报告也将BUFFER CACHE的命中率期望定位在了100%。
众所周知，RAC节点间数据块传输主要采用的是CACHE FUSION机制，也就是说当服务进程发现数据块在本节点中不存在时，会进一步查看数据块在远程节点的BUFFER CACHE中是否存在，如果存在且符合传输条件，则由LMS进程将数据块从远端的BUFFER CACHE传输至本地的BUFFER CACHE中。为了减少数据块在节点间的传递次数，所以提高本地BUFFER CACHE的命中率显得尤为重要。在AWR报告中，有获取远程节点CACHE数据块的统计值。