昨天做技术分享被问到命中率的问题,今天有一个有意思的例子:
SQL1:执行1百万次 但是这个SQL加起来其实就是在10个distinct数据块上不厌其烦的查询
SQL2,SQL3,SQL4,SQL5,SQL6的总和执行了1000次 但是是在10000个distinct的数据块上,由于这些SQL读的块比较离散,大部分都产生的是物理读。
1000000
命中率=------------------=99.9%(我瞎算的,大概接近)
1000000+10000
看到了吧,我们一共有6个SQL,其中一个SQL1的命中率高达100%,其余SQL的命中率接近0%
但是整体的命中率却是99.9%。
想说的是,命中率很多时候会掩盖问题,只能作为一个辅助的参考指标。就我上面举得例子,我们看AWR的命中率可能觉得系统没什么问题,觉得系统的cache最够大了,命中率最够高了
而真实的情况是,大部分的SQL命中率都很差。可能很多SQL存在优化的必要,或者CACHE有扩容的需求。
现在ORACLE都根据OWI(等待事件)这种更科学的诊断来判断数据库问题了,相信大家很熟悉OWI了,命中率只能作为一个辅助的参考指标。
但是整体的命中率却是99.9%。
想说的是,命中率很多时候会掩盖问题,只能作为一个辅助的参考指标。就我上面举得例子,我们看AWR的命中率可能觉得系统没什么问题,觉得系统的cache最够大了,命中率最够高了
而真实的情况是,大部分的SQL命中率都很差。可能很多SQL存在优化的必要,或者CACHE有扩容的需求。
现在ORACLE都根据OWI(等待事件)这种更科学的诊断来判断数据库问题了,相信大家很熟悉OWI了,命中率只能作为一个辅助的参考指标。
关于命中率不科学的其他例子:
一个SQL频繁的做全表扫描(完全可以走索引的),由于CACHE较大,这个表完全可以被CACHE在内存里,那么虽然从报告里看到的命中率很高,但是其实这个SQL的优化空间是极大的,命中率也掩盖了这个问题。
一个SQL频繁的做全表扫描(完全可以走索引的),由于CACHE较大,这个表完全可以被CACHE在内存里,那么虽然从报告里看到的命中率很高,但是其实这个SQL的优化空间是极大的,命中率也掩盖了这个问题。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/22034023/viewspace-763491/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/22034023/viewspace-763491/