数据库Mysql性能优化详解

在mysql数据库中，mysql key_buffer_size是对MyISAM表性能影响最大的一个参数(注意该参数对其他类型的表设置无效)，下面就将对mysql Key_buffer_size参数的设置进行详细介绍下面为一台以MyISAM为主要存储引擎服务器的配置：

分配了512MB内存给mysql key_buffer_size，我们再看一下key_buffer_size的使用情况：

一共有27813678764个索引读取请求，有6798830个请求在内存中没有找到直接从硬盘读取索引，计算索引未命中缓存的概率：

比如上面的数据，key_cache_miss_rate为0.0244%，4000个索引读取请求才有一个直接读硬盘，已经很BT了，key_cache_miss_rate在0.1%以下都很好(每1000个请求有一个直接读硬盘)，所以理论来上来说，这个比值越小越好，但过小的话，难免造成内存浪费。

以上两个值的比率固然能一部分的说明key_buffer_size是否合理，但仅仅以此就说明该值设置的合理的话，就过于偏激和片面了。因为这里忽略了两个问题：

1、比例并不显示数量的绝对值大小

2、计数器并没有考虑时间因素

虽说Key_read_requests大比小好，但是对于系统调优而言，更有意义的应该是单位时间内的Key_reads，即：

Key_reads / Uptime

具体查看方法如下：

注：命令里的mysqladmin ext其实就是mysqladmin extended-status，你甚至可以简写成mysqladmin e。

其中第一行表示的是汇总数值，所以这里不必考虑，下面的每行数值都表示10秒内的数据变化，从这份数据可以看出每10秒系统大约会出现500次Key_reads访问，折合到每1秒就是50次左右，至于这个数值到底合理与否，就由服务器的磁盘能力而定了。(注：我这里之所以数据变化较大，是因为有update等语句造成了表锁而导致下个时间段内的查询数猛增。)

为啥数据按10秒取样，而不是直接按1秒取样？由于时间段过小，数据变化比较剧烈，不容易直观估计大小，所以通常数据按照10秒或者60秒之类的时间段来取样是更好的。