“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控制。

（未完待续）

在这个“Cache为王”的时代，我们总是通过不同的方式去缓存我们的结果从而提高响应效率，但一个缓存机制是否有效，效果如何，却是一个需要好好思考的问题。在MySQL中的Query Cache就是一个适用较少情况的缓存机制。在上图中，如果缓存命中率非常高的话，有测试表明在极端情况下可以提高效率238%^[1]。但实际情况如何？Query Cache有如下规则，如果数据表被更改，那么和这个数据表相关的全部Cache全部都会无效，并删除之。这里“数据表更改”包括: INSERT, UPDATE, DELETE, TRUNCATE, ALTER TABLE, DROP TABLE, or DROP DATABASE等。举个例子，如果数据表posts访问频繁，那么意味着它的很多数据会被QC缓存起来，但是每一次posts数据表的更新，无论更新是不是影响到了cache的数据，都会将全部和posts表相关的cache清除。如果你的数据表更新频繁的话，那么Query Cache将会成为系统的负担。有实验表明，糟糕时，QC会降低系统13%^[1]的处理能力。

如果你的应用对数据库的更新很少，那么QC将会作用显著。比较典型的如博客系统，一般博客更新相对较慢，数据表相对稳定不变，这时候QC的作用会比较明显。

再如，一个更新频繁的BBS系统。下面是一个实际运行的论坛数据库的状态参数：

可以看到，数据库一共往QC中写入了约800W次缓存，但是实际命中的只有约500W次。也就是说，每一个缓存的使用率约为0.66次。很难说，该缓存的作用是否大于QC系统所带来的开销。但是有一点是很肯定的，QC缓存的作用是很微小的，如果应用层能够实现缓存，将可以忽略QC的效果。

————-下面是关于QC的一些其他细节—————–

一、Query Cache相关参数：

• query_cache_size QC占用空间大小，通过将其设置为0关闭QC功能
• query_cache_type 0表示关闭QC；1表示正常缓存；2表示SQL_CACHE才缓存
• query_cache_limit 最大缓存结果集
• query_cache_min_res_unit 手册上说，QC会按照这个值分配缓存block的大小。
• Qcache_lowmem_prunes 这是一个状态变量(show status)，当缓存空间不够需要释放旧的缓存时，该值会自增。

二、Query Cache观察：

CREATE TABLE t1(id INT,var1 varchar(10));
	//Com_select:8	Qcache_hits:1
INSERT INTO t1 VALUES(1,’WWW’);
	//Com_select:8	Qcache_hits:1
SELECT * FROM t1 WHERE id=1;
	//Com_select:9	Qcache_hits:1
SELECT * FROM t1 WHERE id=1;
	//Com_select:9	Qcache_hits:2 Qcache_queries_in_cache:1
INSERT INTO t1 VALUES(2,’RRRR’);
	//Com_select:9	Qcache_hits:2 Qcache_queries_in_cache:0
SELECT * FROM t1 WHERE id=1; //INSERT后Cache失效
	//Com_select:10  Qcache_hits:2 Qcache_queries_in_cache:1

参考：

1. http://dev.mysql.com/doc/refman/5.0/en/query-cache.html
2. http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html
3. http://www.mysqlperformanceblog.com/2006/07/27/mysql-query-cache/

(全文完)

1. 当事务(Transaction)需要修改某条记录（row）时，InnoDB需要将该数据所在的page从disk读到buffer pool中，事务提交后，InnoDB修改page中的记录(row)。这时buffer pool中的page就已经和disk中的不一样了，我们称buffer pool中的page为dirty page。Dirty page等待flush到disk上。
   
   
2. dirty page既然是在Buffer pool中，那么如果系统突然断电Dirty page中的数据修改是否会丢失？这个担心是很有必要的，例如如果一个用户完成一个操作（数据库完成了一个事务，page已经在buffer pool中修改，但dirty page尚未flush），这时系统断电，buffer pool数据全部消失。那么，这个用户完成的操作（导致的数据库修改）是否会丢失呢？答案是不会(innodb_flush_log_at_trx_commit=1)。这就是redo log要做的事情，在disk上记录更新。
3. redo log在每次事务commit的时候，就立刻将事务更改操作记录到redo log。所以即使buffer pool中的dirty page在断电时丢失，InnoDB在启动时，仍然会根据redo log中的记录完成数据恢复。
4. redo log的另一个作用是，通过延迟dirty page的flush最小化磁盘的random writes。（redo log会合并一段时间内TRX对某个page的修改）
   
5. 正常情况下，dirty page什么时候flush到disk上？
   1).redo log是一个环(ring)结构，当redo空间占满时，将会将部分dirty page flush到disk上，然后释放部分redo log。这种情况可以通过Innodb_log_wait(SHOW GLOBAL STATUS)观察，情况发生该计数器会自增一次。
   2).当需要在Buffer pool分配一个page，但是已经满了，并且所有的page都是dirty的（否则可以释放不dirty的page），通常是不会发生的。这时候必须flush dirty pages to disk。这种情况将会记录到Innodb_buffer_pool_wait_free中。一般地，可以可以通过启动参数innodb_max_dirty_pages_pct控制这种情况，当buffer pool中的dirty page到达这个比例的时候，将会强制设定一个checkpoint，并把dirty page flush到disk中。
   3).检测到系统空闲的时候，会flush，每次64 pages。
6. 涉及的InnoDB配置参数：innodb_flush_log_at_trx_commit、innodb_max_dirty_pages_pct；状态参数：Innodb_log_wait、Innodb_buffer_pool_wait_free。

参考文献

1. http://mysqldump.azundris.com/archives/78-Configuring-InnoDB-An-InnoDB-tutorial.html
2. http://dev.mysql.com/doc/refman/5.0/en/innodb.html

1. 在配置文件中可以配置InnoDB的表空间^[1]，一般格式如下(共享表空间)：
   datadir = /opt/mysql/data
   innodb_data_file_path=ibdata1:1G;ibdata2:1G;ibdata3:1G;ibdata4:1G;ibdata5:1G
2. 完整的表空间，会被分成如下结构供给InnoDB使用。最小单位是page，每个page为16K；64个连续的page组成一个extent；多个extent和page构成一个segment。Segment初始时InnoDB会为它分配32个pages，之后根据需要会将extent分配给segment，单次最多会分配4个extends给segment。^[1]
3. 具体的，InnoDB中一个索引（B-tree）由两个segment组成。其中，所有的叶子节点（leaf nodes）存放在一个segment中，所有的非叶子节点（nonleaf nodes）存放在一个segment中。^[1]
4. 一个存放记录(row)的page，由page header、page trailer、page body组成。如下图:^[2]
   
5. 相关的InnoDB的参数:innodb_data_file_path。

参考文献:

1. http://dev.mysql.com/doc/refman/5.0/en/innodb-file-space.html
2. InnoDB Internals: InnoDB File Formats and Source Code Structure,MySQL Conference, April 2009, Heikki Tuuri CEO Innobase, Calvin Sun Principal Engineer, Oracle Corporation

在使用MySQL的应用中，如果你的MySQL Server压力逐渐增大，在应用层优化已经到了一定瓶颈时，那么你应该首先考虑MySQL Replication。本文将利用图示的方式简单的描述出MySQL Replication是如何工作的。

如何同步

1. 主库将所有的更新操作，写入二进制日志。
2. 从库运行”IO线程”（Slave IO Thread）读取主库的二进制日志。
3. 从库运行”SQL线程”（Slave SQL Thread）执行IO线程（Slave IO Thread）读取的日志中的SQL,从而保持和主库的一致。

如何分配请求

1. 目前，这部分需要在应用层实现。
2. 执行更新SQL(UPDATE，INSERT，DELETE)时，请求主库。
3. 执行查询SQL(SELECT)时，请求从库。

所以，当你的应用(Application)SELECT请求所占的比率越大，那么Relication就会越有效。