首页 > MySQL > 详解MyISAM Key Cache

详解MyISAM Key Cache

“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 ),下面是一些规则:

多个没有更新操作的session可以并发同一个block buffer

多个session同时访问某一个block buffer,如果某个session是update操作,则优先访问

多个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控制。

前篇中介绍了Key Cache的基本机制,并且介绍了Key Cache的LRU算法。作为对LRU算法的改进,MyISAM还提供了另一个缓存算法:“Midpoint Insertion Strategy”。本文将重点介绍该算法的原理和配置。

1. 相关参数

该策略涉及的参数有:key_cache_division_limitkey_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的顶部。注意,warm sub-chain 顶部是最优先被替换掉的,也即key block 从hot sub-chain到warm sub-chain将很快被替换

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

3. 如何使用Midpoint Insertion Strategy

我们可以通过配置key_cache_division_limitkey_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被移除的机制(参照前文介绍)。

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

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

1. 如何配置Key Cache的大小

#配置文件my.cnf
key_buffer_size=50*1024*1024

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

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

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

SET GLOBAL hot_cache.key_buffer_size=128*1024;
CACHE INDEX t1 IN hot_cache;
SET GLOBAL hot_cache.key_buffer_size=0;

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

LOAD INDEX INTO CACHE t1, t2

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

5. 需要注意的事项

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

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

首先,刷新数据表,并锁住数据表:(注意,请不要在业务高峰期执行

FLUSH TABLES WITH READ LOCK;

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

最后,移动对应的文件(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.”)。

原文:http://www.orczhou.com/index.php/2010/01/myisam-key-buffer-1/

分类: MySQL 标签: , , ,
  1. 本文目前尚无任何评论.
  1. 本文目前尚无任何 trackbacks 和 pingbacks.

=5加3(必填)请输入两数相加的结果。