昨天做技術分享被問到命中率的問題，今天有一個有意思的例子：

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了，命中率只能作為一個輔助的參考指標。

關於命中率不科學的其他例子：
一個SQL頻繁的做全表掃描（完全可以走索引的），由於CACHE較大，這個表完全可以被CACHE在記憶體裡，那麼雖然從報告裡看到的命中率很高，但是其實這個SQL的最佳化空間是極大的，命中率也掩蓋了這個問題。

關於ORACLE裡的buffer cache 的命中率

相關文章