设为首页 收藏本站
查看: 1016|回复: 0

[经验分享] mysql 优化心得

[复制链接]

尚未签到

发表于 2016-9-12 10:47:05 | 显示全部楼层 |阅读模式
  mysql的优花其实是个艰难的工作,要搞的东西太多了,之前在http://www.cnblogs.com/jackyrong/archive/2008/05/04/1182331.html
中摘了一些原则,最近对一个100多万条数据的表做优花时,有如下心得:

1) 取必须要用的数据
    这里对于select 语句中只选有用的字段,这样的原则就肯定人人都知道的了。但关键的是,要从全局考虑问题,比如我的这个应用
是每个新闻网页的跟帖,一条新闻有很多很多人跟帖,平均有40-50条,那么每天这么多新闻,很多的跟帖记录,但对于审帖
者,由于是每天上班工作的,每天他们会把当天的帖子审核掉,因此,在做记录列表时,只需要选用出当前时间以内1-2天的记录就可以了,
这里已经是大大优化
2 ) 建好索引
     这里的学问太多,也太多文章讲,这里不说
3 ) MYSQL的优化
      第三个工作才是MYSQL的优化,其实就是改my.ini,有如下几点,归纳下.(我的是4G内存的双核机器)
   A 设置key_buffer_size
   key_buffer_size指定索引缓冲区的大小,这个值越高,索引可以使用的内存越多,一般为可用内存的25-30%,它决定索引处理的速度,尤其是索引读的速度。通过检查状态值Key_read_requestsKey_reads,可以知道key_buffer_size设置是否合理。比例key_reads / key_read_requests应该尽可能的低,至少是1:1001:1000更好(上述状态值可以使用SHOW STATUS LIKE ‘key_read%’获得)。
key_buffer_size只对MyISAM表起作用。即使你不使用MyISAM表,但是内部的临时磁盘表是MyISAM表,也要使用该值。可以使用检查状态值created_tmp_disk_tables得知详情。
对于1G内存的机器,如果不使用MyISAM表,推荐值是16M8-64M)。

 B max_connections数量
     MYSQL建议使用table_cache=max_connection*N来设置tablecache,N为标准连接中表的数量
 C table_cache
  
table_cache指定表高速缓存的大小。每当MySQL访问一个表时,如果在表缓冲区中还有空间,该表就被打开并放入其中,这样可以更快地访问表内容。通过检查峰值时间的状态值Open_tablesOpened_tables,可以决定是否需要增加table_cache的值。如果你发现open_tables等于table_cache,并且opened_tables在不断增长,那么你就需要增加table_cache的值了(上述状态值可以使用SHOW STATUS LIKE ‘Open%tables’获得)。注意,不能盲目地把table_cache设置成很大的值。如果设置得太高,可能会造成文件描述符不足,从而造成性能不稳定或者连接失败。
对于有1G内存的机器,推荐值是128256
D 提高order by groud by的速度,通过设置sort_buufer变量进行控制,还可以增加read_rnd_buffer_size变量值,也可以增加read_buffer_size值,提高select的查询速度
 E query_cache_size
4.0.1开始,MySQL提供了查询缓冲机制。使用查询缓冲,MySQLSELECT语句和查询结果存放在缓冲区中,今后对于同样的SELECT语句(区分大小写),将直接从缓冲区中读取结果。根据MySQL用户手册,使用查询缓冲最多可以达到238%的效率。
通过检查状态值Qcache_*,可以知道query_cache_size设置是否合理(上述状态值可以使用SHOW STATUS LIKE ‘Qcache%’获得)。如果Qcache_lowmem_prunes的值非常大,则表明经常出现缓冲不够的情况,如果Qcache_lowmem_prunes增长迅速,意味着很多缓存因为内存不够而被释放,而不是因为相关表被更新。尝试加大query_cache_size,尽量使Qcache_lowmem_prunes零增长。
如果Qcache_hits的值也非常大,则表明查询缓冲使用非常频繁,此时需要增加缓冲大小;如果Qcache_hits的值不大,则表明你的查询重复率很低,这种情况下使用查询缓冲反而会影响效率,那么可以考虑不用查询缓冲。此外,在SELECT语句中加入SQL_NO_CACHE可以明确表示不使用查询缓冲。
    

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.iyunv.com/thread-271181-1-1.html 上篇帖子: MySQL Variable解读 下篇帖子: mysql操作blob
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表