咨询热线:4006-75-4006
售前:9:00-23:30 备案:9:00-18:00 技术:7*24h
本文适合初步接触者做一些参考,老手就不用这样去操作了,希望有不对的多多指教。
重要强调!本人并不是专业DBA,难免有错误或遗漏的地方,还请大家给予指正。操作前做好备份。
重要强调!本人并不是专业DBA,难免有错误或遗漏的地方,还请大家给予指正。操作前做好备份。
重要强调!本人并不是专业DBA,难免有错误或遗漏的地方,还请大家给予指正。操作前做好备份。
先说一下,这里通过宝塔来操作的,开始前先来两张图
图一
图二
1、活动/峰值连接数
(图1)中当前活动的连接为1个,自MySQL服务启动以来,最高连接数为54;当最高连接数接近或等于(图2)中的max_connections时,应适当增加max_connections,需要注意的是,不要一下子增加过多,建议每次增加50,观察一段时间,不够再继续增加。
2、线程缓存命中率
(图1)中线程缓存命中率为99.78%,若这个值小于90%,建议适当增加(图2)中的thread_cache_size,建议每次增加8。
3、索引命中率
(图1)中索引命中率为99.50%,若这个值小于95%,建议适当增加(图2)中的key_buffer_size,建议每次增加64,需要说明的是,若您的数据库使用的是Innodb引擎,可忽略这个选项
4、Innodb索引命中率
(图1)中Innodb索引命中率为100%,若这个值小于95%,建议适当增加(图2)中的innodb_buffer_pool_size,建议每次增加64,需要说明的是,若您的数据库没有使用Innodb引擎,可忽略这个选项
5、查询缓存命中率
MySQL查询缓存是个比较受争议的功能,个人建议当你有在使用redis、memcached等缓存软件时,在(图2)中将query_cache_size设为0可以将其关闭,当你没有使用缓存软件,有多余的内存使用,且数据库瓶颈明显存在时,可以尝试开启查询缓存,这是个非常依赖数据表结构及SQL语句优化的功能,若数据表结构和SQL语句都针对查询缓存进行过优化,它的效果还是很不错的。
6、创建临时表到磁盘
(图1)中创建临时表到磁盘的比例是0.42%,这说明大部分临时表创建到内存了,不会过多增加磁盘IO的开销,建议,当比例大于2%时适当增加(图1)中的tmp_cache_size,建议每次增加32,当比例大于60%时,放弃吧,有些开源程序并没有专门优化过SQL语句,所以在运行过程中会开启大量临时表,加多少缓存都是不够用的。
7、已打开的表
当(图1)中的已打开的表接近或等于(图2)中的table_open_cache时,可以适当增加table_open_cache,但若设置过大可能导致您的程序频繁中断MySQL连接,建议在1024以内,最大不要超过2048。
8、没有使用索引的量、没有使用索引的JOIN量
若不为0,就检查下数据表索引吧,其实只要没有疯涨,比如一天增涨几千,一般可以忽略,必竟优化索引还是程序员或DBA去干比较合适。
9、排序后的合并次数
如果这个值在缓慢增张,建议适当增加(图2)中的sort_buffer_size,建议每次增加512,但最大不要超过8192,如果这个值一直在疯涨,增加sort_buffer_size也没用,就放弃这个选项吧,这个锅还是给程序开发者背。
10、锁表次数
如果服务器CPU开销不大的情况下,疯狂锁表,建议你将所有数据表转换成innodb,记得转换前备份哦。
11、优化方案
这个是我们根据内存大小给的一个推荐优化方案,仅是建议仅用于基础参考值,还是要根据实据情况来调整每一个配置项。
希望大家通过自己的不断观察,不断调整,找到最适合自己的,关于调优,没有最好的参数,只有最适合自己的。加油。