1、buffer pool这种大块头，能在运行期间动态调整大小吗？

其实如果就我们讲的这套原理的话，buffer pool在运行期间是不能动态的调整自己的大小的 为什么呢？因为动态调整buffer pool大小，比如buffer pool本来是8G，运行期间你给调整为16G了，此时是怎么实 现的呢？ 就是需要这个时候向操作系统申请一块新的16GB的连续内存，然后把现在的buffer pool中的所有缓存页、描述数据 块、各种链表，都拷贝到新的16GB的内存中去。这个过程是极为耗时的，性能很低下，是不可以接受的！ 所以就目前讲解的这套原理，buffer pool是绝对不能支持运行期间动态调整大小的。

2、如何基于chunk机制把buffer pool给拆小呢？

但是MySQL自然会想办法去做一些优化的，他实际上设计了一个chunk机制，也就是说buffer pool是由很多chunk组 成的，他的大小是innodb_buffer_pool_chunk_size参数控制的，默认值就是128MB。 所以实际上我们可以来做一个假设，比如现在我们给buffer pool设置一个总大小是8GB，然后有4个buffer pool，那 么每个buffer pool就是2GB，此时每个buffer pool是由一系列的128MB的chunk组成的，也就是说每个buffer pool 会有16个chunk。 然后每个buffer pool里的每个chunk里就是一系列的描述数据块和缓存页，每个buffer pool里的多个chunk共享一套 free、flush、lru这些链表，此时的话，看起来可能大致如下图所示。

在上面的图里，可以清晰的看到，每个buffer pool里已经有了多个chunk，每个chunk就是一系列的描述数据块和缓 存页，这样的话，就是把buffer pool按照chunk为单位，拆分为了一系列的小数据块，但是每个buffer pool是共用一套 free、flush、lru的链表的。

3、基于chunk机制是如何支持运行期间，动态调整buffer pool大小的？

那么现在有了上面讲的这套chunk机制，就可以支持动态调整buffer pool大小了。 比如我们buffer pool现在总大小是8GB，现在要动态加到16GB，那么此时只要申请一系列的128MB大小的chunk就 可以了，只要每个chunk是连续的128MB内存就行了。然后把这些申请到的chunk内存分配给buffer pool就行了。 有个这个chunk机制，此时并不需要额外申请16GB的连续内存空间，然后还要把已有的数据进行拷贝。 给大家讲解这个chunk机制，倒不是让大家在数据库运行的时候动态调整buffer pool大小，其实这不是重点，重点是 大家要了解数据库的buffer pool的真实的数据结构，是可以由多个buffer pool组成的，每个buffer pool是多个 chunk组成的，然后你只要知道他运行期间可以支持动态调整大小就可以了。