昨天做技术分享被问到命中率的问题，今天有一个有意思的例子：
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博客 ” ，链接：https://blog.itpub.net/22034023/viewspace-763491/ ，如需转载，请注明出处，否则将追究法律责任。
请登录后发表评论
登录
全部评论
