InnoDB的缓冲池(buffer pool)类似于oracle的sga，里面存放数据页、索引页、change buffer、ahi等内容。
每次读写数据都需要通过buffer pool，当buffer pool中没有用户所需要的数据时则去硬盘中获取。

通过缓冲池操作数据流程
innodb_buffer_pool_size参数控制缓冲池的总容量，5.7开始的版本可以在线动态调整该参数，一般来说，越大性能越好，如果所有热数据都能缓存到缓冲池中，那样性能是非常可观的。
Ⅱ、缓冲池的性能问题
2.1 性能线性扩展
假设一台服务器72core，ht超线程后，144个逻辑core，压测时按道理144个core都应该跑满，如果跑不满就说明并发有瓶颈，加的core用不上，性能上不去。
5.1之前的版本常常被吐槽这个问题，现在已经不存在这个问题。
1G空间中有65536个页，对这些页进行管理，每次操作都要对缓冲池加锁(latch，不是数据库的lock)，如果缓冲池太大了就会产生瓶颈。
qps达到1w，每秒钟至少要获取1w次latch，这里只看缓冲池的latch，忽略latch的释放和唤醒，开销非常大。
如何提升缓冲池性能
调整innodb_buffer_pool_instances参数，设置为cpu的数量。
假设开始这个值是1，现调整为4，原来1个缓冲池管理65536个页，现在4个缓冲池，每个缓冲池管理16384个页，拆成4个分片，将热点打散，latch变少了，并发性能提升了。
这是非常常见的内核层对并发调优的手段，经测试，不调整与调整后性能相差30%。
注意：
设置多个缓冲池的时候，必须满足每个池子大于1G才生效。
Ⅲ、缓冲池的管理
3.1 缓冲池的组成
缓冲池核心组成
缓冲池中的热点是以页为单位来管理，并不是三种List加起来等于总的bp大小，而是Free List + LRU List(Flush List包含在LRU list中)。
Free List放空白的page，MySQL刚启动时，缓冲池中有一个个16K的空白的页，这些页存放在（链表串联）在Free List中。
LRU List包括LRU和unzip_LRU，当读取一个数据页的时候，就从Free List中取出一个页，存入数据，并将该页放入LRU List中。
当Free List给一个页给LRU List时，这个过程中需要一个并发控制，也就是之前说的latch。假设现在有两个线程都读到磁盘上这个页，则都需要问Free List来申请空闲页，谁先来先给谁，latch就是对这三个List进行并发控制访问的。
Flush List组织脏页（被修改但未刷入磁盘的数据页），根据每个脏页的oldest_lsn进行排序。假设被读到的页，马上被更新，这个页就叫脏页，会被放入到Flush List列表中，但只是放了一个指针(page Number)，而不是实际的页
