同时在线访问量继续增大 对于G内存的服务器明显感觉到吃力严重时甚至每天都会死机 或者时不时的服务器卡一下 这个问题曾经困扰了我半个多月MySQL使用是很具伸缩性的算法因此你通常能用很少的内存运行或给MySQL更多的被存以得到更好的性能
安装好mysql后配制文件应该在/usr/local/mysql/share/mysql目录中配制文件有几个有f f f f不同的流量的网站和不同配制的服务器环境当然需要有不同的配制文件了
一般的情况下f这个配制文件就能满足我们的大多需要一般我们会把配置文件拷贝到/etc/f 只需要修改这个配置文件就可以了使用mysqladmin variables extendedstatus –u root –p 可以看到目前的参数有３个配置参数是最重要的即key_buffer_sizequery_cache_sizetable_cache
key_buffer_size只对MyISAM表起作用
key_buffer_size指定索引缓沖区的大小它决定索引处理的速度尤其是索引读的速度一般我们设为M实际上稍微大一点的站点这个数字是远远不够的通过检查状态值Key_read_requests和Key_reads可以知道key_buffer_size设置是否合理比例key_reads / key_read_requests应该尽可能的低至少是::更好（上述状态值可以使用SHOW STATUS LIKE key_read%获得） 或者如果你装了phpmyadmin 可以通过服务器运行状态看到笔者推荐用phpmyadmin管理mysql以下的状态值都是本人通过phpmyadmin获得的实例分析:
这个服务器已经运行了天
key_buffer_size – M key_read_requests – key_reads
比例接近: 健康状况非常好
另外一个估计key_buffer_size的办法把你网站数据库的每个表的索引所占空间大小加起来看看以此服务器为例:比较大的几个表索引加起来大概M 这个数字会随着表变大而变大
从开始MySQL提供了查询缓沖机制使用查询缓沖MySQL将SELECT语句和查询结果存放在缓沖区中今后对于同样的SELECT语句（区分大小写）将直接从缓沖区中读取结果根据MySQL用户手册使用查询缓沖最多可以达到%的效率
通过调节以下几个参数可以知道query_cache_size设置得是否合理
Qcache inserts Qcache hits Qcache lowmem prunes Qcache free blocks Qcache total blocks
Qcache_lowmem_prunes的值非常大则表明经常出现缓沖不够的情况同时Qcache_hits的值非常大则表明查询缓沖使用非常频繁此时需要增加缓沖大小Qcache_hits的值不大则表明你的查询重复率很低这种情况下使用查询缓沖反而会影响效率那么可以考虑不用查询缓沖此外在SELECT语句中加入SQL_NO_CACHE可以明确表示不使用查询缓沖
Qcache_free_blocks如果该值非常大则表明缓沖区中碎片很多query_cache_type指定是否使用查询缓沖
我设置:
query_cache_size = M
query_cache_type=
得到如下状态值:
Qcache queries in cache 表明目前缓存的条数
Qcache inserts
Qcache hits 看来重复查询率还挺高的
Qcache lowmem prunes 有这么多次出现缓存过低的情况
Qcache not cached
Qcache free memory 目前剩余缓存空间
Qcache free blocks 这个数字似乎有点大碎片不少
Qcache total blocks
如果内存允许M应该要往上加点
table_cache指定表高速缓存的大小每当MySQL访问一个表时如果在表缓沖区中还有空间该表就被打开并放入其中这样可以更快地访问表内容通过检查峰值时间的状态值Open_tables和Opened_tables可以决定是否需要增加table_cache的值如果你发现open_tables等于table_cache并且opened_tables在不断增长那么你就需要增加table_cache的值了（上述状态值可以使用SHOW STATUS LIKE Open%tables获得）注意不能盲目地把table_cache设置成很大的值如果设置得太高可能会造成文件描述符不足从而造成性能不稳定或者连接失败
对于有G内存的机器推荐值是－
笔者设置table_cache =
得到以下状态:
Open tables
Opened tables
虽然open_tables已经等于table_cache但是相对于服务器运行时间来说已经运行了天opened_tables的值也非常低因此增加table_cache的值应该用处不大如果运行了个小时就出现上述值 那就要考虑增大table_cache
如果你不需要记录进制log 就把这个功能关掉注意关掉以后就不能恢复出问题前的数据了需要您手动备份二进制日志包含所有更新数据的语句其目的是在恢复数据库时用它来把数据尽可能恢复到最后的状态另外如果做同步复制( Replication )的话也需要使用二进制日志传送修改情况
log_bin指定日志文件如果不提供文件名MySQL将自己产生缺省文件名MySQL会在文件名后面自动添加数字引每次启动服务时都会重新生成一个新的二进制文件此外使用logbinindex可以指定索引文件使用binlogdodb可以指定记录的数据库使用binlogignoredb可以指定不记录的数据库注意的是binlogdodb和binlogignoredb一次只指定一个数据库指定多个数据库需要多个语句而且MySQL会将所有的数据库名称改成小写在指定数据库时必须全部使用小写名字否则不会起作用
关掉这个功能只需要在他前面加上#号
#logbin
开启慢查询日志( slow query log )
慢查询日志对于跟蹤有问题的查询非常有用它记录所有查过long_query_time的查询如果需要还可以记录不使用索引的记录下面是一个慢查询日志的例子
开启慢查询日志需要设置参数log_slow_querieslong_query_timeslogqueriesnotusingindexes
log_slow_queries指定日志文件如果不提供文件名MySQL将自己产生缺省文件名long_query_times指定慢查询的阈值缺省是秒logqueriesnotusingindexes是以后引入的参数它指示记录不使用索引的查询笔者设置long_query_time=
笔者设置:
sort_buffer_size = M max_connections= wait_timeout = back_log= read_buffer_size = M thread_cache= interactive_timeout= thread_concurrency =
参数说明:
back_log
要求MySQL能有的连接数量当主要MySQL线程在一个很短时间内得到非常多的连接请求这就起作用然后主线程花些时间(尽管很短)检查连接并且启动一个新线程back_log值指出在MySQL暂时停止回答新请求之前的短时间内多少个请求可以被存在堆栈中只有如果期望在一个短时间内有很多连接你需要增加它换句话说这值对到来的TCP/IP连接的侦听队列的大小你的操作系统在这个队列大小上有它自己的限制 Unix listen()系统调用的手册页应该有更多的细节检查你的OS文档找出这个变量的最大值试图设定back_log高于你的操作系统的限制将是无效的
max_connections
并发连接数目最大 超过这个值就会自动恢复出了问题能自动解决
thread_cache
没找到具体说明不过设置为后 天才创建了多个线程 而以前一天就创建了上千个线程 所以还是有用的
thread_concurrency
#设置为你的cpu数目x例如只有一个cpu那么thread_concurrency=
#有个cpu那么thread_concurrency=
skipinnodb
#去掉innodb支持
