MySQL Innodb資料庫效能實踐——熱點資料效能

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

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

【硬體設定】

硬體	配置
CPU	Intel(R) Xeon(R) CPU E5620 主頻2.40GHz， 物理CPU 2個，邏輯CPU 16個
記憶體	24G（6塊 * 4G  DDR3 1333 REG）
硬碟	300G * 3個，SAS硬碟 15000轉，無RAID，有RAID卡，且開了回寫功能
OS	RHEL5
MySQL	5.1.49/5.1.54

【MySQL配置】

配置項	配置
innodb_buffer_pool_size	4G
innodb_log_file_size	200M
innodb_log_files_in_group	3
sync_binlog	100
innodb_flush_log_at_trx_commit	2

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

項目	模型
表記錄數	1KW(3G)，2KW(6G)，5KW(15G)，10KW(30G)
Key	INT
Value	CHAR(250)
熱點資料	佔總資料20%

效能測試結果如下：

【查詢】

詳細分析如下：

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

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

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

【插入】

詳細分析如下：

==>當熱點資料小於Innodb buffer pool時（1KW/2KW/5KW），效能隨著熱點資料的增長而逐漸下降，原因是當Innodb buffer pool接近飽和時，buffer管理需要進行更多的操作；

==>當熱點資料超過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（即熱點資料全部能夠放入記憶體）時，才能夠獲得高效能。

註：
測試資料只為對比用，不代表一般情況下MySQL的效能就這麼高，因為為了能夠對比，測試時做了很多準備工作，測試操作也是比較特殊的