MySQL优化 推荐

thread_concurrency
数量设置为CPU核心数量的两倍.
thread_cache_size
按照内存大小来设置, 1G=8, 2G=16, 3G=32, >3G=64
wait_timeout
超时时间,如果连接数比较大,可以减少此参数的值,我使用的是10
max_connections
最大连接数,mysql实际允许连接数的值是max_connections+1,按照系统库不同而有不同性能.一般是500~1000,MySQL AB提供的linux静态库可以达到4000.
query_cache_size
查询缓冲,默认是0,所以必须打开以提高mysql性能,其本身需要40K来保存结构数据.所以不能设置的太小,初期可以设置成32M,然后根据实际运行情况另行调整
query_cache_type
指定查询缓冲的类型,0是关闭,1是缓冲除了使用SELECT SQL_NO_CACHE语句指明了不需要缓冲的数据意外的所有查询,2是只缓冲SELECT SQL_CACHE指定的查询.一般设置为1.
query_cache_limit
允许进入查询缓冲区的最小数据大小,默认值是1MB,可以修改的小一点以满足更多查询的需求.但是如果设置的过于小,则会导致很多新的小查询的结果将原有的查询结果交换出去.增加系统的颠簸.

相关命令
查询mysql服务器相关状态数据
>SHOW STATUS;

查询mysql服务器相关配置选项
>SHOW VARIABLES;

整理查询缓冲区里的碎片
>flush query cache;

删除查询缓冲区里的所有内容
>reset query cache;

设置mysql参数
>SET GLOBAL;

变量 含义
Qcache_queries_in_cache
在缓存中已注册的查询数目
Qcache_inserts
被加入到缓存中的查询数目
Qcache_hits
缓存采样数数目
Qcache_lowmem_prunes
因为缺少内存而被从缓存中删除的查询数目
Qcache_not_cached
没有被缓存的查询数目 (不能被缓存的，或由于 QUERY_CACHE_TYPE)
Qcache_free_memory
查询缓存的空闲内存总数
Qcache_free_blocks
查询缓存中的空闲内存块的数目
Qcache_total_blocks
查询缓存中的块的总数目

MySQL查询优化
>SHOW STATUS LIKE ‘Qcache%’;
查询出Cache状态
如果Qcache_lowmem_prunes非常大,说明因为内存不足而被交换出cache的数据很多.如果增加内存.可以保证较小的交换次数以及较高的命中率
例如现在我们查询的结果如下

设置为64M cache内存后
>set global query_cache_size=67108864;

自由内存块看起来变小了
是因为现在自由内存块.是一个整块.而以前的内存块都是分散的小块
而因为重建了cache区
Qcache_queries_in_cache变量变小了.因为此操作重新建立了cache内存区.所有数据重新缓存
在运行一两天后我们再看此数据.如果变大了.说明增大cache内存区域是有效的.如果和以前数据差不多
说明增加的内存并没有实际起到多大的作用.

有人会觉得如果我将cache内存设置的非常大
然后将cache_limit设置成0
那么所有查询都会被缓存了
理论上是这样.但是一台数据库服务器的查询非常多.
如果连查询单条数据都要缓存.
那么内存再大也会不够的.到时候老的内容就会被交换出去
当cache内存使用满的时候,就会不停的有新查询进来将老查询替换出去.
这样导致两个结果.一个是内存颠簸.效率反而下降.
第二个是cache内存的小碎块增多,内存利用率降低
如果是只有内容很少的小库,并且查询率不高.是可以使用这种方法提高响应速度
但是如果是实际生产环境,数据量会比较大.还是需要按照最佳比例来配置.
而不同的应用不同的数据量会有不同的搭配,这点大家不要看网上的优化配置随便的填写
还是要时时的查看mysql的状态进行调整.即便是这个月调整好的优化参数
到了下个月业务不同,数据量增加,也会需要调整的.