mysql在大数据量下性能调优相关参数

摘自http://blog.csdn.net/nightelve/article/details/17393631

一、thread_concurrency,默认的8

thread_concurrency的值的正确与否, 对mysql的性能影响很大, 在多个cpu(或多核)的情况下,错误设置了thread_concurrency的值, 会导致mysql不能充分利用多cpu(或多核), 出现同一时刻只能一个cpu(或核)在工作的情况。
thread_concurrency应设为CPU核数的2倍. 比如有一个双核的CPU, 那thread_concurrency 的应该为4; 2个双核的cpu, thread_concurrency的值应为8.
比如:根据上面介绍我们目前系统的配置,可知道为4个CPU,每个CPU为8核,按照上面的计算规则,这儿应为:4*8*2=64
查看系统当前thread_concurrency默认配置命令:

show variables like ‘thread_concurrency‘;

二、key_buffer_size,默认为384M

key_buffer_size是用于索引块的缓冲区大小,增加它可得到更好处理的索引(对所有读和多重写),对MyISAM(MySQL表存储的一种类型,可以百度等查看详情)表性能影响最大的一个参数。如果你使它太大,系统将开始换页并且真的变慢了。严格说是它决定了数据库索引处理的速度,尤其是索引读的速度。对于内存在4GB左右的服务器该参数可设置为256M或384M.
怎么才能知道key_buffer_size的设置是否合理呢,一般可以检查状态值Key_read_requests和Key_reads ,比例key_reads / key_read_requests应该尽可能的低,比如1:100,1:1000 ,1:10000。其值可以用以下命令查得:

show status like ‘key_read%‘;

比如查看系统当前key_read和key_read_request值为:

+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| Key_read_requests | 28535 |
| Key_reads | 269 |
+-------------------+-------+
可知道有28535个请求,有269个请求在内存中没有找到直接从硬盘读取索引.
未命中缓存的概率为:0.94%=269/28535*100%. 一般未命中概率在0.1之下比较好。目前已远远大于0.1,证明效果不好。若命中率在0.01以下,则建议适当的修改key_buffer_size值。

三、innodb_buffer_pool_size(默认128M)

innodb_buffer_pool_size:主要针对InnoDB表性能影响最大的一个参数。功能与Key_buffer_size一样。InnoDB占用的内存,除innodb_buffer_pool_size用于存储页面缓存数据外,另外正常情况下还有大约8%的开销,主要用在每个缓存页帧的描述、adaptive hash等数据结构,如果不是安全关闭,启动时还要恢复的话,还要另开大约12%的内存用于恢复,两者相加就有差不多21%的开销。假设:12G的innodb_buffer_pool_size,最多的时候InnoDB就可能占用到14.5G的内存。若系统只有16G,而且只运行MySQL,且MySQL只用InnoDB,
那么为MySQL开12G,是最大限度地利用内存了。
另外InnoDB和 MyISAM 存储引擎不同, MyISAM 的 key_buffer_size 只能缓存索引键,而 innodb_buffer_pool_size 却可以缓存数据块和索引键。适当的增加这个参数的大小,可以有效的减少 InnoDB 类型的表的磁盘 I/O 。
当我们操作一个 InnoDB 表的时候,返回的所有数据或者去数据过程中用到的任何一个索引块,都会在这个内存区域中走一遭。
可以通过 (Innodb_buffer_pool_read_requests – Innodb_buffer_pool_reads) / Innodb_buffer_pool_read_requests * 100% 计算缓存命中率,并根据命中率来调整 innodb_buffer_pool_size 参数大小进行优化。值可以用以下命令查得:

show status like ‘Innodb_buffer_pool_read%‘;

比如查看当前系统中系统中

+---------------------------------------+---------+

| Innodb_buffer_pool_read_requests | 1283826 |
| Innodb_buffer_pool_reads | 519 |
+---------------------------------------+---------+
其命中率99.959%=(1283826-519)/1283826*100% 命中率越高越好。

四、innodb_additional_mem_pool_size(默认8M)

innodb_additional_mem_pool_size 设置了InnoDB存储引擎用来存放数据字典信息以及一些内部数据结构的内存空间大小,所以当我们一个MySQL Instance中的数据库对象非常多的时候,是需要适当调整该参数的大小以确保所有数据都能存放在内存中提高访问效率的。
这个参数大小是否足够还是比较容易知道的,因为当过小的时候,MySQL会记录Warning信息到数据库的error log中,这时候你就知道该调整这个参数大小了。
查看当前系统mysql的error日志 cat /var/lib/mysql/机器名.error 发现有很多waring警告。所以要调大为20M.
根据MySQL手册,对于2G内存的机器,推荐值是20M。
32G内存的 100M

时间: 2024-08-11 12:22:48

mysql在大数据量下性能调优相关参数的相关文章

一招教你解决大数据量下的各种报表使用问题

在我们日常制作报表分析过程中,总会遇到各种问题.比如,报表底层数据日益增多.报表加载超慢,这些情况该怎么解决? 数据库是最常见的能处理大数据的计算方案,而永洪能利用数据库来完成数据计算.但是,有些报表的计算较为复杂,使用SQL实现会非常困难,这时,我们就会采用永洪报表呈现的直观计算方式来完成数据的计算,这种方式导致后台要直接处理大数据,不仅性能低下,而且很容易造成报表加载时间过长. 今天这篇文章,主要介绍永洪数据集市数据集,这种方式提供强大.便捷的数据处理方式,用户可以轻松应对大数据量场景下报表

大数据量下高并发同步的讲解(转)

文章转自:http://blog.csdn.net/xcw931924821/article/details/52475742 *************************************************************************************************************************************************************************************** 对于

大数据量下高并发同步的讲解(不看,保证你后悔)

对于我们开发的网站,如果网站的访问量非常大的话,那么我们就需要考虑相关的并发访问问题了.而并发问题是绝大部分的程序员头疼的问题, 但话又说回来了,既然逃避不掉,那我们就坦然面对吧~今天就让我们一起来研究一下常见的并发和同步吧. 为了更好的理解并发和同步,我们需要先明白两个重要的概念:同步和异步    1.同步和异步的区别和联系          所谓同步,可以理解为在执行完一个函数或方法之后,一直等待系统返回值或消息,这时程序是出于阻塞的,只有接收到 返回的值或消息后才往下执行其它的命令. 异步

大数据量下高并发同步的讲解(不看,保证你后悔!)

偶然的机会在网上看到了这篇blog,觉得作者写得挺不错的(虽然自己并没有怎么看懂...),所以就转来跟大家分享分享吧~~~ 对于我们开发的网站,如果网站的访问量非常大的话,那么我们就需要考虑相关的并发访问问题了.而并发问题是绝大部分的程序员头疼的问题, 但话又说回来了,既然逃避不掉,那我们就坦然面对吧~今天就让我们一起来研究一下常见的并发和同步吧. 为了更好的理解并发和同步,我们需要先明白两个重要的概念:同步和异步    1.同步和异步的区别和联系          所谓同步,可以理解为在执行完

大数据量下的SQL Server数据库自身优化 (转载)

1.1:增加次数据文件 从SQL SERVER 2005开始,数据库不默认生成NDF数据文件,一般情况下有一个主数据文件(MDF)就够了,但是有些大型的数据库,由于信息很多,而且查询频繁,所以为了提高查询速度,可以把一些表或者一些表中的部分记录分开存储在不同的数据文件里 由于CPU和内存的速度远大于硬盘的读写速度,所以可以把不同的数据文件放在不同的物理硬盘里,这样执行查询的时候,就可以让多个硬盘同时进行查询,以充分利用CPU和内存的性能,提高查询速度. 在这里详细介绍一下其写入的原理,数据文件(

大数据量下高并发同步的讲解

对于我们开发的网站,如果网站的访问量非常大的话,那么我们就需要考虑相关的并发访问问题了.而并发问题是绝大部分的程序员头疼的问题, 但话又说回来了,既然逃避不掉,那我们就坦然面对吧~今天就让我们一起来研究一下常见的并发和同步吧. 为了更好的理解并发和同步,我们需要先明白两个重要的概念:同步和异步    1.同步和异步的区别和联系         所谓同步,可以理解为在执行完一个函数或方法之后,一直等待系统返回值或消息,这时程序是出于阻塞的,只有接收到 返回的值或消息后才往下执行其它的命令. 异步,

大数据量下的高并发分布式访问控制(ACL)优化方案(一)

目前的设计方案 1.1.控制计数: 在目前的项目中,有很多接口需要对访问方进行权限访问控制.目前设计方案是:利用redis集群来存储每个访问控制点的访问计数信息.Key值为=PlatformId(接入平台方)+InterfaceId(系统接口)+dayTime(日期时间),value值为当天每个时段的访问次数统计列表. 1.2.控制规则: 通过页面配置并制定控制规则.业务系统在启动时加载控制规则,并访问redis获取控制次数,然后在业务系统中做逻辑判断完成,ACL控制做请求拦截处理. 目前的痛点

大数据量下MySQL插入方法的性能比较

不管是日常业务数据处理中,还是数据库的导入导出,都可能遇到需要处理大量数据的插入.插入的方式和数据库引擎都会对插入速度造成影响,这篇文章旨在从理论和实践上对各种方法进行分析和比较,方便以后应用中插入方法的选择. 插入分析 MySQL中插入一个记录需要的时间由下列因素组成,其中的数字表示大约比例: 连接:(3) 发送查询给服务器:(2) 分析查询:(2) 插入记录:(1x记录大小) 插入索引:(1x索引) 关闭:(1) 如果我们每插入一条都执行一个SQL语句,那么我们需要执行除了连接和关闭之外的所

总结MySQL大数据量下如何进行优化

写在建库前: 在确定数据库业务后.建立数据库表格时,就应对一些常见问题有所考虑,以避免在数据增长一段时间后再做应对,可能造成时间及维护成本增加: 数据的月增量,年增量 数据的快速增长点 是否需要触发器或事件等 查询业务需求 服务器访问量 以上的考虑项,对数据库的类型.表的结构.表间关系的定义及数据库配置都有非常重要的影响. 运行后优化: 优化顺序 第一,优化你的sql和索引: 想实现一个查询,可以写出很多种查询语句,不同的语句,根据你选择的引擎.表中数据的分布情况.索引情况.数据库优化策略.查询