終端用戶訪問加速節點時，如果該節點有快取住了要被訪問的數據時就叫做命中，如果沒有的話需要回原伺服器取，就是沒有命中。取數據的過程與用戶訪問是同步進行的，所以即使是重新取的新數據，用戶也不會感覺到有延時。 命中率=命中數/（命中數+沒有命中數）， 快取命中率是判斷加速效果好壞的重要因素之一。
基本介紹
- 中文名：快取命中率
- 外文名：Cache Hit Rate
- 取決於：很多的因素
- 類型：非常適合快取套用的場景
影響因素,套用場景,快取的粒度,架構的設計,快取的容量,實際案例,
影響因素
快取的命中率取決於很多的因素：
套用場景
是OLTP還是OLAP套用，即使是OLTP，也要看訪問的頻度，一個極少被訪問到的快取等於沒有什麼效果。一般來說，網際網路網站是非常適合快取套用的場景。
快取的粒度
毫無疑問，快取的粒度越小，命中率就越高，對象快取是目前快取粒度最小的，因此被命中的幾率更高。舉個例子來說吧：你訪問當前這個頁面，瀏覽帖子，那么對於ORM來說，需要傳送n條SQL，取各自帖子user的對象。很顯然，如果這個user在其他帖子裡面也跟貼了，那么在訪問那個帖子的時候，就可以直接從快取裡面取這個user對象了。
架構的設計
架構的設計對於快取命中率也有至關重要的影響。例如你應該如何去儘量避免快取失效的問題，如何儘量提供頻繁訪問數據的快取問題，這些都是考驗架構師水平的地方。再舉個例子來說，對於論壇，需要記錄每個topic的瀏覽次數，所以每次有人訪問這個topic，那么topic表就要update一次，這意味著什麼呢？對於topic的對象快取是無效的，每次訪問都要更新快取。那么可以想一些辦法，例如增加一個中間變數記錄點擊次數，每累計一定的點擊，才更新一次資料庫，從而減低快取失效的頻率。
快取的容量
快取太小，造成頻繁的LRU，也會降低命中率，快取的有效期太短也會造成快取命中率下降。
所以快取命中率問題不能一概而論，一定說命中率很低或者命中率很高。但是如果你對於快取的掌握很精通，有意識的去調整套用的架構，去分解快取的粒度，總是會帶來很高的命中率的。
實際案例
這裡我可以舉一個實際的案例，JavaEye2.0網站在使用對象快取之前，通過MySQL的監控工具進行觀察，在連續24小時的平均每秒傳送SQL條數超過了200條，在使用對象快取之後，連續24小時的平均每秒傳送SQL條數下降到了120條左右，幾乎下降了一半。
考慮到很多SQL都是分頁語句，關聯查詢，條件查詢，集合操作，都是不能被快取的SQL，而真正能夠被快取的SQL只有根據主鍵查詢對象和對象關聯對象的查詢。所以真正能夠被快取的SQL估計最多占所有SQL的60%。所以換算下來，套用快取的命中率之高，已經相當驚人了。
不過這裡要提醒的一點，有將近一半的SQL都被快取，不意味著性能可以提升一倍。這是因為能夠被快取的都是按照主鍵查詢單條記錄的SQL，這些SQL本身即使傳送到資料庫，對資料庫造成的壓力也沒有想像的那么大。真正對資料庫造成龐大壓力的正是那些沒有索引的大表查詢，和造成了全表掃描的關聯查詢，這些一旦涉及到全表掃描的查詢，才是性能的真正殺手。當然了，不管怎么說，通過使用對象快取，是毫無疑問可以大幅度降低資料庫的負載壓力的，有效提升web套用的性能的。
