在数据库数据处理中， 缓冲在改善性能方面扮演着很重要的角色， 为了保证性能， innodb 维护了自己的缓冲池。 文章大体介绍一下innodb缓冲区实现和管理策略。
在innodb中，需要用到数据页(需要保存到磁盘的数据)均是从这个缓冲池里分配出来的， 因此，可以说，缓冲池在对innodb的性能有很大的影响。
几个基本的概念
AWE:地址窗口化扩展,允许在 32 位版本的 Windows 操作系统上使用 4 GB 以上的物理内存。最多可支持 64 GB 的物理内存。更多信息请看 http://baike.baidu.com/view/1390438.htm； innodb是支持AWE内存管理的
Frame；帧，16K的虚拟地址空间， 在缓冲池的管理上，整个缓冲区是是以大小为16k的frame(可以理解为数据块)为单位来进行的，frame是innodb中页的大小。
Page: 页，16K的物理内存， page上存的是需要保存到磁盘上的数据， 这些数据可能是数据记录信息， 也可以是索引信息或其他的元数据等；
Control Block：控制块，对于每个frame, 有一个block， block上的信息是专门用于进行frame控制的管理信息， 但是这些信息不需要记录到磁盘，而是根据读入数据块在内存中的状态动态生成的， 主要包括： 1. 页面管理的普通信息，互斥锁， 页面的状态， awe（windows平台上awe机制的管理信息)等 2. 脏回写(flush)管理信息3. lru控制信息 4. 快速查找的管理信息， 为了便于快速的超找某一个block或frame， 缓冲区里面的block被组织到一些hash表中; 缓冲区中的block的数量是一定得， innodb缓冲区对所管理的block用lru策略进行替换。
互斥访问
缓冲池的整个缓冲区有一个数据结构buf_pool进行管理和控制， 有一个专门的mutex保护着， 这个mutex是用来保护buf_pool这个控制结构中的数据域的， 并不保护缓冲区中的数据frame以及用于管理的block, 缓冲区里block或者frame中的访问是由专门的读写锁来保护的， 每个block/frame有一个。在5.1以前， 每个block是没有专门的mutex保护的，如果需要进行互斥保护，直接使用缓冲区的mutex, 结果导致很高的争用； 5.1以后，每个block有一个mutex对其进行保护， 从而在很大程度上解缓了对buf_pool的mutex的争用。
缓冲池管理用到的几个重要的列表
在缓冲区的管理中， 有几个重要的block列表(双向链表)：
LRU列表： 用来进行lru管理的列表， 列表里的每个block所控制的数据都是当前有效的数据；列表中的block基本是按照访问的顺序排列的；最近被访问的放在最前面， 最先被方位的放在最后；lru列表中维护中维护了一个LRU_old, 大概指向整个列表的倒数3/8左右， 当增加一个新的block(主语与最近被访问的block的区别)进来的时候， 把新的块刚好放到这个点附近， 具体是前还是后取决于这个LRU_old目前的位置， 这么做的目的是使新增加进来的block放到一个合适的位置， 不至于放到最先(最近被使用过)或最后(最老）
flush列表： 列表block是那些所管理的数据被修改但是还没有更新到磁盘的脏frame, 根据修改的先后顺序排列的block列表， 最老的放最后。innodb起来后， 主线程会定期去检查
缓冲区中可用空闲block的数量的比例， 一旦大于srv_max_buf_pool_modified_pct(90%), 就会试图把一些脏页flush到磁盘；除了主线程会定期做这个事情外，工作线程在进行数据操作时 ，如果发现没有如果的block， 也会通过flush一些脏页来腾出空间。
free list, 所有空闲block的列表， 当需要分配一个block时， 从中取出一个block。
awe_LRU_free_mapped： 用于方便awe的block列表， 这些block所管理的page已经映射到了frame(物理内存有对应的虚拟内存空间)，其中的元素必定也处于free列表或lru列表中。 这个列表会在当分配一个awe页面时用到。
adaptive hash search: 缓冲区中的页面是通过双向列表的方式组织起来的， 如果需要查找根据页号查找某个页面block的话， 速度不会快，尤其是数据块多的时候； 为了加速查找过程，在用双向列表组织block的时候，也采用了adaptive hash的数据组织， hash的键值(key)是页号(数据页在所在表空间的编号)， 这个在一定程度上能加速block的查找， 但是当以awe方式管理内存的话，这种hash查找方式不会启用。
页面读入机制
当读入页面的时候， 首先需要找到一个可用的block， 这个block或者来自于free list或者lru-list; 在读入数据块的时候， block会加上排他锁以防止其他线程再次使用这个block，
会在block中标记出这个块正处于io状态， 然后把io请求加入到io调用请求对列； 完成读入操作时， 再释放block上的拍它锁更新io状态。
数据页面的读取写入
缓冲池中的数据基本是采用同步aio的方式，这里的同步aio的意思是： 工作线程发出读或写请求后，请求会被放到一个读写请求队列中，由专门的io线程负责写盘和读盘，而工作线程则等待io的完成，
注意， 这里是等待完成，而不会放弃执行，因而称作为同步aio.
提前读(预读)机制
为了优化数据读入性能， 缓冲区读入采取了提前读的机制（当然，这个机制可以配置成不激活），当然， 提前读的机制是基于数据局部性的原理来的，
这就是为什么采用取值过于随机的字段作为主键会导致性能降低的原因之一：过于随机的主键会导致提前读不起作用， 而且会导致更多的换页行为； 这个预读取对于上层的功能如索引管理是透明的，
对于上层的功能来说， 需要提供的信息是需要读取的页是否有后继页和前置页。 有两种预读机制: 线性预读和随机预读
线性预读： 当第一读缓冲区中某一个已经存在(注意，这里必须是已经存在于缓冲区额数据块)的数据块时， 会检查这个数据块是不是处于所谓的线性预读区域(比如， 区域大小是64， 当前读入的也是100，那么所在的预读区域是65 ~ 128)，如果是， 则统计一下这个区域中目前没有被访问过的页面，如果数量多于预读机制设定的预读数量，则放弃本次预读， 这个其实是检查目前的区域是否还有大量的页面没有被访问过， 如果是的话， 自然没有必要去做预读了； 否则， 取得读取页面的后继页和前置页(按照数据页的自然顺序?，然后检查后继页或者前置页是否是一个新区域的边界，如果是， 则发出读取
该区域里面的数据页面的异步请求。
随机读: 当读取一个页面时， 根据所读取页的位置计算出该页面所在的随机预读区域， 区域的计算也基于设定的区域页面数量来计算的(如前面关于线性预读的例子)， 然后根据lru对列的信息计算该区域中有多少块最近被访问到了， 如果被访问的数量达到一定的额度(这个额度是根据预读区域的大小计算出来的， 5 + 预读区域大小 / 8)，则预读取该区域中目前还没有读取到缓冲区的块.
show innodb status 中关于buffer pool的输出
Buffer pool size 262144 整个缓冲池中的页的数量， 包括flush列表中的和flush列表中的，以及被分配出去的页的数量
Free buffers 0 free列表中的页的数量
Database pages 258053 分配出去， 正在被使用页的数量
Modified db pages 37491 flush列表中的数量
Pending reads 0 发出了请求但没有完成的io读个数
Pending writes: LRU 0, flush list 0, single page 0 发出了请求但没有完成的io读个数在各个列表上的体现
Pages read 57973114, created 251137, written 10761167， 从磁盘上读取出来的页数， 在内存中建立了页面但是没有从磁盘上读取出来的页面数以及写入了的页面数
9.79 reads/s, 0.31 creates/s, 6.00 在刚过去的时间间隔里， 平均每秒的读取数和新建数
Buffer pool hit rate 999 / 1000 命中率， 缓冲区中读到的页 / 总共发出的读页数
与缓冲池相关的状态变量及含义
| Innodb_buffer_pool_pages_data 分配出去， 正在被使用页的数量
| Innodb_buffer_pool_pages_dirty 脏页但没有被flush除去的页面数
| Innodb_buffer_pool_pages_flushed 已经flush的页面数
| Innodb_buffer_pool_pages_free 当前空闲页面数
| Innodb_buffer_pool_pages_latched 当前被锁住的页面数
| Innodb_buffer_pool_pages_misc 用于管理功能的页面数， 如adaptive hash等
| Innodb_buffer_pool_pages_total 缓冲区总共的页面数
| Innodb_buffer_pool_read_ahead_rnd 随机预读的次数
| Innodb_buffer_pool_read_ahead_seq 线性预读的次数
| Innodb_buffer_pool_read_requests 总共从缓冲池中缓存的页面中读取出的页数
| Innodb_buffer_pool_reads 从磁盘上一页一页的读取的页数，从缓冲池中读取页面， 但缓冲池里面没有， 就会从磁盘读取
| Innodb_buffer_pool_wait_free 缓冲池等待空闲页的次数， 当需要空闲块而系统中没有时， 就会等待空闲页面
| Innodb_buffer_pool_write_requests 缓冲池总共发出的写请求次数
| Innodb_data_fsyncs 总共完成的fsync次数
| Innodb_data_pending_fsyncs innodb当前等待的fsync次数
| Innodb_data_pending_reads innodb当前等待的读的次数
| Innodb_data_pending_writes innodb当前等待的写的次数
| Innodb_data_read | 总共读入的字节数
| Innodb_data_reads innodb完成的读的次数
| Innodb_data_writes innodb完成的写的次数
| Innodb_data_written 总共写出的字节数
命中率=innodb_buffer_pool_read_requests / (innodb_buffer_pool_read_requests + innodb_buffer_pool_read_ahead + innodb_buffer_pool_reads)
平均每次读取的字节数= innodb_data_read / innodb_data_reads
注：innodb_buffer_pool_read_requests：从缓冲池中读取页的次数
Innodb_buffer_pool_read_ahead：预读的次数
Innodb_buffer_pool_reads：从磁盘读取页的次数
Innodb_data_read：读入的字节数
Innodb_data_reads：发起读取请求的次数，每次读取可能需要读取多个页
