在前两篇（前篇、中篇）中，分别介绍了Key Cache的基本原理（LRU和Midpoint Insertion Strategy）。最后，将介绍一些相关的参数、状态参数和命令。

Key Cache的配置很灵活，可以针对全局配置，还可以针对某个单独数据表分配Key Cache的大小；如果一个数据表某部分的索引块被访问的非常频繁（较之其他索引块），那么可以配置Midpoint Insertion Strategy达到最大的利用率(参考)。

1. 如何配置Key Cache的大小

另外，Key Cache的大小可以动态的改变

2. 给数据表划分单独的Key Cache

例如：划分一块128K的Key buffer空间，指定数据表t1的Key cache放在里面。最后演示了如何删除这个特定的Key buffer空间。

3. 预先载入某些数据表的索引

4. 关于Key Cache的使用情况观察 Flush现象

mysql> show status like "key%"; 
+------------------------+----------+
| Variable_name          | Value    |
+------------------------+----------+
| Key_blocks_not_flushed | 14468    | 
| Key_blocks_unused      | 0        | 
| Key_blocks_used        | 14497    | 
| Key_read_requests      | 30586575 | 
| Key_reads              | 157      | 
| Key_write_requests     | 7100408  | 
| Key_writes             | 1199800  | 
+------------------------+----------+
mysql> flush tables;             （注意，请不要在业务高峰期执行）
+------------------------+----------+
| Variable_name          | Value    |
+------------------------+----------+
| Key_blocks_not_flushed | 0        |   #所有修改的block都已经被flush了
| Key_blocks_unused      | 0        | 
| Key_blocks_used        | 14497    | 
| Key_read_requests      | 38333936 | 
| Key_reads              | 207      | 
| Key_write_requests     | 8819898  | 
| Key_writes             | 1255245  | 
+------------------------+----------+

5. 需要注意的事项

内存中缓存的索引块（Key Cache），有时候并不会及时刷新到磁盘上，所以对于正在运行的数据表的索引文件（MYI）一般都是不完整的。如果此时拷贝或者移动这些索引文件。多半会出现索引文件损坏的情况。

可以通过Flush table命令来将Key Cache中的block都flush到磁盘上。所以，一般要动态移动MyISAM表需要执行以下步骤：

首先，刷新数据表，并锁住数据表：（注意，请不要在业务高峰期执行）

可以通过下面的命令来查看没有被Flush的索引块数量

mysql> show status like "Key_blocks_not_flushed"; 
+------------------------+----------+
| Variable_name          | Value    |
+------------------------+----------+
| Key_blocks_not_flushed | 0        | 
+------------------------+----------+

最后，移动对应的文件（MYI MYD FRM）。

参考

1. MySQL Manual about Key cache

Update 2010-03-01:

在Why you should ignore MySQL’s key cache hit ratio中，Baron Schwartz提到很多关于Key Cache命中率的问题：一般情况，诸如“命中率”这样参数本身的意义并不明显，历史数据对比才比较靠谱（文中提到的“Key_reads/Uptime”）；关于Key_buffer_size大小，Baron Schwartz认为并没有统一的标准，而是应该具体情况具体分析，大小尽量大于你最常被访问的Key block（ “In my opinion, you should choose a key_buffer_size that is large enough to hold your working set — the index blocks that are frequently used.”）。