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."）。

1. 相关参数

该策略涉及的参数有：key_cache_division_limit、key_cache_age_threshold

2. 原理介绍

(1) 该策略将前面的LRU队列（LRU Chain）分成两部分，hot sub-chain和warm sub-chain。并根据参数key_cache_division_limit划分，总保持warm sub-chain在这个百分比以上。默认情况key_cache_division_limit是100，所以默认时候只有warm sub-chain,即LRU Chain。
(注：Multiple Key cache情况，每个key cache都有对应的key_cache_division_limit值)

(2) 在warm sub-chain中的某个block如果被访问（Access）次数超过某个值时候，就将该block放到hot sub-chain的底部。

(3) 在hot sub-chain中的block会随着每一次的hit调整位置，hit越多，越接近底部。在顶部停留时间过长就会被降级到warm sub-chain中，而且是warm sub-chain的顶部（很可能很快就会被移出key cache）。

(4) Hot sub-chain中的顶部的block停留时间超过一个阈值后就会被降级到warm sub-chain。这个阈值由参数key_cache_age_threshold决定。具体的计算方法是：设N为key cache中的block个数，如果在最近的（N*key_cache_age_threshold/100）次访问中，key cache顶部的block仍然没有被访问到，那么就会被移到warm sub-chain的顶部。

(5) 默认情况key_cache_division_limit = 100，这时只有只有一个Chain，所以不使用该策略。即退化的Midpoint Insertion Strategy是LRU算法。

3. 如何使用Midpoint Insertion Strategy

我们可以通过配置key_cache_division_limit、key_cache_age_threshold的值来控制。参数key_cache_division_limit控制了Key Cache Chain中warm sub-chain的百分比，如果你的Index Block中明显有30%是非常Hot（较之其他的Block更加被常常访问），那么你可以设置你的warm sub-chain长度为70%，剩余30%作为hot sub-chain。参数key_cache_age_threshold定义了warm sub-chain中的block被移除的机制（参照前文介绍）。

（未完待续）

“Cache为王”，无所不在。为了最小化磁盘I/O，MyISAM将最频繁访问的索引块（“index block”）都放在内存中，这样的内存缓冲区我们称之为Key Cache，它的大小可以通过参数key_buffer_size来控制。在MyISAM的索引文件中（MYI），连续的单元（contiguous unit）组成一个Block，Index block的大小等于该BTree索引节点的大小。Key Cache就是以Block为单位的。

1. MyISAM如何使用Key Cache

当MySQL请求(读或写)MyISAM索引文件中某个Index Block时，首先会看Key Cache队列中是否已经缓存了对应block。如果有，就直接在Key Cache队列中进行读写了，不再需要请求磁盘。如果是写请求，那么Key Cache中的对应Block就会被标记为Dirty（和磁盘不一致）。在MyISAM在Key Cache成功请求（读写）某个Block后，会将该Block放到Key Cache队列的头部。

如果Key Cache中没有待请求（读或写）的Block，MyISAM会向磁盘请求对应的Block，并将其放到Key Cache的队列头部。队列如果满了，会将队列尾部的Block删除，该Block如果是Dirty的，会将其Flush到磁盘上。我们看到MyISAM维护了一个LRU（Least Recently Used）的Key Cache队列。队列中的Dirty Block会在Block被踢出队列时Flush到磁盘上。

2. 图解

下图展示了访问Index Block的过程：（黑色部分为磁盘中的Index文件）

3. 并发访问

Key Cache中的index Block是可以被并发访问的（Shared access ），下面是一些规则：

1. 多个没有更新操作的session可以并发同一个block buffer
2. 多个session同时访问某一个block buffer，如果某个session是update操作，则优先访问
3. 多个session如果都需要进行block replacement，是可以并发操作。（从index file中读取block更新到key cache，但是key cache已满，需要删除一些block buffer的操作叫做block replacement）

4. 补充说明

Key cache中的Block大小可能和索引文件中的Index Block大小不同，可能是大于、小于、等于中的任何一种，但是一般都是成倍数关系的。Key Cache的block大小由参数Key_cache_block_size控制。

（未完待续）