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的性能就这么高,因为为了能够对比,测试时做了很多准备工作,测试操作也是比较特殊的

时间: 2024-12-03 21:21:26

MySQL Innodb数据库性能实践——热点数据性能的相关文章

求大神帮忙 MySQL 去掉数据库中重复的数据,保留一条

问题描述 求大神帮忙 MySQL 去掉数据库中重复的数据,保留一条 解决方案 mysql中删除两条重复的数据,只保留一条mysql 删除重复数据只保留一条mysql删除重复数据只保留一条 解决方案二: 菜鸟的答复: ** 删除前先备份一下,万一错了,我不管 ** /* 假设你的表叫table_car */ DELETE FROM table_car WHERE car_id NOT IN (SELECT MIN(car_id) FROM table_car GROUP BY car_line_i

MySQL Innodb数据库性能实践——VARCHAR vs CHAR

学过数据库理论的读者,都应该还记得关于CHAR和VARCHAR的性能对比:CHAR比VARCHAR更快,因为CHAR是固定长度的,而VARCHAR需要增加一个长度标识,处理时需要多一次运算. 针对这种情况,我做了一下基准测试,基准测试环境如下: [硬件配置] 硬件 配置 CPU Intel(R) Xeon(R) CPU E5620 主频2.40GHz, 物理CPU 2个,逻辑CPU 16个 内存 24G(6块 * 4G  DDR3 1333 REG) 硬盘 300G * 3个,SAS硬盘 150

MySQL Innodb数据库性能实践——合适的表记录数

在实际工作中,经常有同事问道:MySQL Innodb表记录数多大是合适的? 一般的理解肯定是表越大性能越低,但具体低多少呢,是缓慢下降还是急剧下降,是1000万就下降还是1亿才下降呢? 针对这些问题,我做了一下基准测试,基准测试环境如下: [硬件配置] 硬件 配置 CPU Intel(R) Xeon(R) CPU E5620 主频2.40GHz, 物理CPU 2个,逻辑CPU 16个 内存 24G(6块 * 4G  DDR3 1333 REG) 硬盘 300G * 3个,SAS硬盘 15000

MySQL Innodb数据库性能实践

在实际工作中,经常有同事问道:MySQL Innodb表记录数多大是合适的? 一般的理解肯定是表越大性能越低,但具体低多少呢,是缓慢下降还是急剧下降,是1000万就下降还是1亿才下降呢? 针对这些问题,我做了一下基准测试,基准测试环境如下: [硬件配置] 硬件 配置 CPU Intel(R) Xeon(R) CPU E5620 主频2.40GHz, 物理CPU 2个,逻辑CPU 16个 内存 24G(6块 * 4G  DDR3 1333 REG) 硬盘 300G * 3个,SAS硬盘 15000

MYSQL INNODB 组合索引分支节点数据解析

1.本文证明组合索引的所有键值在分支节点(非叶子结点也进行了存储). 2.本文给出B+ 索引如何进行验证其B+树结构 关于B树结构(不是B+树)可以参考: http://blog.itpub.net/7728585/viewspace-2126929/ 脚本: mysql> create table testzh(id int  primary key auto_increment ,id2 int,id3 int,name varchar(20), key(id2,id3)); Query O

独家丨专访雅捷信息董事长、NVIDIA全球副总裁,看“非主流”的GPU数据库如何升级银行数据查询与加工

2012 年,正在哈佛大学写硕士论文的 Todd Mostak 需要查询大量的论文参考资料,他发现使用以 CPU 为处理核心的数据库系统做资料查询速度非常缓慢.而且很多时候,Todd Mostak 在睡觉之前输入一个查询命令,第二天醒来发现系统提示参数输入错误. 当时 Todd Mostak 选修了由 MIT 数据库研发组教授的 CSAIL 数据库课程,为了加快论文进度,Todd Mostak 通过自己在 CSAIL 数据库课程中学到的知识开发了一个简易的数据库系统,该数据库是通过使用廉价的.为

MYSQL 大数据性能优化

批量插入优化 在网上找了一些插入大量数据性能优化资料,提到了比较重要的一点是将 Java代码   insert into tablename(f1,f2,...) values (d1,d2,...);   insert into tablename(f1,f2,...) values (d1,d2,...);   ...    这样的单条单条的insert语句改造成 Java代码   insert into tablename(f1,f2,...) values (d1,d2,...),(d1

反驳"MySQL InnoDB (不行)的性能问题",千万级别记录来测试说明

在 JavaEye 上看到一篇对 MySQL FUD(Fear, uncertainty and doubt) 的文章 用MySQL InnoDB Benchmark 性能测试来说明 http://www.javaeye.com/topic/34676 文中提到:"InnoDB 的磁盘性能很令人担心,MySQL 缺乏良好的 tablespace 真是天大的缺陷! --网上有用户反映存在同样的插入性能问题,百万行记录插入之后,插入速度下降到了 1/30,从开始的 1600行/秒衰退到 50行/秒-

云服务器 ECS 配置:利用MySQL读写分离,提升应用数据吞吐性能

利用MySQL读写分离,提升应用数据吞吐性能 背景 一般情况下,对数据库的读和写都在同一个数据库服务器中操作时,业务系统性能会降低.为了提升业务系统性能,优化用户体验,可以通过读写分离来减轻主数据库的负载.本篇文章分别从应用层和系统层来介绍读写分离的实现方法. 应用层实现方法: 应用层中直接使用代码实现,在进入Service之前,使用AOP来做出判断,是使用写库还是读库,判断依据可以根据方法名判断,比如说以query.find.get等开头的就走读库,其他的走写库. 优点: 1.多数据源切换方便