mysql优化：Key_buffer_size

在mysql数据库中，mysql key_buffer_size是对MyISAM表性能影响最大的一个参数(注意该参数对其他类型的表设置无效)，下面就将对mysql Key_buffer_size参数的设置进行详细介绍。

下面为一台以MyISAM为主要存储引擎服务器的配置：

mysql> show variables like 'key_buffer_size';
+-----------------+----------+
| Variable_name   | Value    |
+-----------------+----------+
| key_buffer_size | 72454144 |
+-----------------+----------+
1 row in set (0.25 sec)

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

mysql> show global status like 'key_read%';
+-------------------+----------+
| Variable_name     | Value    |
+-------------------+----------+
| Key_read_requests | 39393115 |
| Key_reads         | 174565   |
+-------------------+----------+
2 rows in set (0.23 sec)

上面有2个结果值，这里解释一下它们各代表什么意思：

Key_read_requests：表示从缓存读取索引的请求次数

Key_reads：从磁盘读取索引的请求次数

知道了这2个参数各代表什么意思了，我们可以看到：一共有39393115个请求从缓存读取索引，174565个请求从磁盘读取索引。

让我们来计算一下索引未命中缓存的概率：

key_cache_miss_rate = Key_reads / Key_read_requests * 100%

通过上面的公式我们计算上面数据索引为命中缓存的概率值为：0.4431%，约250个索引读取请求就有一个直接读硬盘，这个值好像不是很理想。key_cache_miss_rate在0.1%以下都很好(每1000个请求有一个直接读硬盘)，所以理论来上来说，这个比值越小越好，但过小的话，难免造成内存浪费。

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

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

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

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

Key_reads / Uptime

具体查看方法：

[root@li411-195 ~]# /usr/local/mysql/bin/mysqladmin ext -uroot -p -ri10 | grep Key_reads
Enter password: 
| Key_reads                      | 174983       |
| Key_reads                      | 10           |
| Key_reads                      | 0            |
| Key_reads                      | 4            |
| Key_reads                      | 0            |
| Key_reads                      | 0            |
| Key_reads                      | 0            |
| Key_reads                      | 0            |
| Key_reads                      | 0            |
| Key_reads                      | 0            |
| Key_reads                      | 0            |
| Key_reads                      | 21           |
| Key_reads                      | 0            |
| Key_reads                      | 0            |

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

其中第一行表示的是汇总数值，所以这里不必考虑，下面的每行数值都表示10秒内的数据变化。

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

对于我这个小站来说，流量小，这个数据结果值并不能说明什么问题。

除些之外，我们还可以参考下key_blocks_*参数：

mysql> show global status like 'key_blocks_u%';
+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| Key_blocks_unused | 28271 |
| Key_blocks_used   | 34395 |
+-------------------+-------+

Key_blocks_unused表示未使用的缓存簇(blocks)数，Key_blocks_used表示曾经用到的最大的blocks数。从上面的数据可以看到Key_blocks_unused 并没有被完全使用，如果Key_blocks_unused 值为0，说明缓存都被使用了，要么增加key_buffer_size，要么就是过渡索引了，把缓存占满了。比较理想的设置：

Key_blocks_used / (Key_blocks_unused + Key_blocks_used) * 100% ≈ 80%

根据以上公式，上面数据的计算结果值大概为55%，说明这里设置也不是很合理。其实这里的值也存在一些问题，就是没有考虑到时间问题，这个数据可能是访问量少的时候获取的，如果访问量大的时候数据结果值可能就又不一样了，所以也不能仅凭这个结果值来判断key_buffer_size值设置是否合理。