MySQL Innodb数据库性能实践——热点数据性能

对于大部分的应用来说，都存在热点数据的访问，即：某些数据在一定时间内的访问频率要远远高于其它数据。
常见的热点数据有“最新的新闻”、“最热门的新闻”、“下载量最大”的电影等。

为了了解MySQL Innodb对热点数据的支持情况，我进行了基准测试，测试环境如下：

【硬件配置】

硬件	配置
CPU	Intel(R)Xeon(R)CPUE5620主频2.40GHz，物理CPU2个，逻辑CPU16个
内存	24G（6块*4GDDR31333REG）
硬盘	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%数据作为热点数据加载到内存，例如：SELECTCOUNT(*)FROMBT_KV_SHORT_INT_CHAR_10KWWHEREcol1<20000000

项目	模型
表记录数	1KW(3G)，2KW(6G)，5KW(15G)，10KW(30G)
Key	INT
Value	CHAR(250)
热点数据	占总数据20%

性能测试结果如下：

【查询】

详细分析如下：

==>当热点数据小于Innodbbufferpool时（1KW/2KW/5KW），查询操作的性能很高，和表数据小于Innodbbufferpool时的性能相近；

==>当热点数据大于Innodbbufferpool时（10KW），查询的性能下降明显；

==>热点数据访问的总体性能优于随机访问；

【插入】

详细分析如下：

==>当热点数据小于Innodbbufferpool时（1KW/2KW/5KW），性能随着热点数据的增长而逐渐下降，原因是当Innodbbufferpool接近饱和时，buffer管理需要进行更多的操作；

==>当热点数据超过Innodbbufferpool后（10KW），性能急剧下降，原因是磁盘IO已经成为性能瓶颈；

【更新】

分析同INSERT。

【删除】

分析如下：

==>和INSERT/UPDATE表现略微不同，当热点数据小于Innodbbufferpool时，性能变化不大，因为DELETE操作不需要生成新的Page，节省了buffer管理的操作；

==>当热点数据大于Innodbbufferpool时，性能下降较大，原因是此时磁盘IO已经成为性能瓶颈。

【总结】
Innodbbufferpool采用LRU的方式管理和淘汰数据，根据LRU算法，热点数据都会优先放入内存，因此热点数据的测试性能比随机访问的要高出不少。
但热点数据超出Innodbbufferpool后，磁盘IO成为性能主要瓶颈，性能会急剧下降。

【应用建议】
实际应用中涉及热点数据访问时，Innodb是一个高性能的较好的选择，但前提是要能够预估热点数据的大小，只有当热点数据小于Innodb buffer pool（即热点数据全部能够放入内存）时，才能够获得高性能。

注：
测试数据只为对比用，不代表一般情况下MySQL的性能就这么高，因为为了能够对比，测试时做了很多准备工作，测试操作也是比较特殊的