對於大部分的應用來說，都存在熱點資料的訪問，即：某些資料在一定時間內的訪問頻率要遠遠高於其它資料。
常見的熱點資料有“最新的新聞”、“最熱門的新聞”、“下載量最大”的電影等。

為了瞭解MySQL Innodb對熱點資料的支援情況，我進行了基準測試，測試環境如下：

【硬體配置】

【熱點資料模型】
為了模擬熱點資料主要儲存在記憶體中的情況，使用範圍查詢將前20%資料作為熱點資料載入到記憶體，例如：SELECT COUNT(*) FROM BT_KV_SHORT_INT_CHAR_10KW WHERE col1 < 20000000

效能測試結果如下：

【查詢】

詳細分析如下：

==>當熱點資料小於Innodb buffer pool時（1KW/2KW/5KW），查詢操作的效能很高，和表資料小於Innodb buffer pool時的效能相近；

==> 當熱點資料大於Innodb buffer pool時（10KW），查詢的效能下降明顯；

==> 熱點資料訪問的總體效能優於隨機訪問；

詳細分析如下：

==>

==>當熱點資料超過Innodb buffer pool後（10KW），效能急劇下降，原因是磁碟IO已經成為效能瓶頸；

【更新】

分析同INSERT。

【刪除】

分析如下：

==>和INSERT/UPDATE表現略微不同，當熱點資料小於Innodb buffer pool時，效能變化不大，因為DELETE操作不需要生成新的Page，節省了buffer管理的操作；

==> 當熱點資料大於Innodb buffer pool時，效能下降較大，原因是此時磁碟IO已經成為效能瓶頸。

【總結】
Innodb buffer pool採用LRU的方式管理和淘汰資料，根據LRU演算法，熱點資料都會優先放入記憶體，因此熱點資料的測試效能比隨機訪問的要高出不少。
但熱點資料超出Innodb buffer pool後，磁碟IO成為效能主要瓶頸，效能會急劇下降。

【應用建議】
實際應用中涉及熱點資料訪問時，Innodb是一個高效能的較好的選擇，但前提是要能夠預估熱點資料的大小，只有當熱點資料小於Innodb buffer pool（即熱點資料全部能夠放入記憶體）時，才能夠獲得高效能。