40
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 |
|
配置項 |
配置 |
|
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的性能就這麼高，因為為了能夠對比，測試時做了很多準備工作，測試操作也是比較特殊的
最後更新：2017-04-02 06:52:16