全部博文(2065)
分类: Mysql/postgreSQL
2010-03-08 22:27:46
“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 ),下面是一些规则:
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_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被移除的机制(参照前文介绍)。
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)。
参考
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.”)。