我們都知道，在讀取頁面時，需要先將頁面從磁碟讀取到記憶體中，然後等待CPU對資料進行處理。我們直到從磁碟中讀取資料到記憶體的過程是十分慢的，所以我們讀取的頁面需要將其快取起來，所以MySQL有這個buffer pool對頁面進行快取。
首先MySQL在啟動時會向作業系統申請一段連續的記憶體空間，這段空間就是作為buffer pool所用。將快取的頁面放入buffer pool中管理起來。
mysql> show variables like 'innodb_buffer_pool_size'; +-------------------------+-----------+ | Variable_name | Value | +-------------------------+-----------+ | innodb_buffer_pool_size | 134217728 | +-------------------------+-----------+ 1 row in set, 1 warning (0.00 sec)
我們可以看到預設是134217728字節，即128MB。若我們申請的快取區大小是16KB的倍數，則不會有碎片問題，因為每個頁面大小都是16KB。
每個頁面都包含其對應的控制塊訊息，這些訊息儲存在buffer pool中。每個控制塊對應管理每一個頁面 (我們使用地址引用每一個頁面) ，控制塊用來存儲頁面的一些信息，控制塊的佔用大小不包括在innodb_buffer_pool_size中。由MySQL在啟動時自行額外申請空間。
由於無法充分利用空間，控制區塊和快取頁之間會存在一些不規則的碎片。因為MySQL向作業系統申請的記憶體空間需要申請一定大小的控制區塊空間，無法確定具體的大小，難免回有無法利用的空間。
free鍊錶顧名思義，就是管理空閒的快取頁面的鍊錶，如果快取頁沒有被使用，其控制區塊就會連接到free鍊錶上。
透過一個基底節點連接控制塊形成一個free鍊錶，並儲存空閒頁的數量等基本資訊。
當我們從磁碟讀取一個頁到buffer pool中，就會取一個空閒的控制區塊填入對應快取頁的基本資訊。
MySQL在buffer pool怎麼快速存取一個頁，以及看對應頁有沒有被快取到buffer pool呢？
這就是用到雜湊表，在Java中就是hashmap，透過表空間 頁號做處理形成一個hash的key值，然後value值就是快取頁在buffer pool中的位址。
學習到這一章節的時候我震驚了，首先確實和我的理解是不一樣的，以及到後面的MVCC確實讓我大開眼界，這是我學習一遍後回頭的總結，所以比較言簡意賅哈。
我們使用SQL語句對某筆記錄進行修改的時候，就會修改某個頁面或多個頁面，我們對於頁面的修改呢，並不會直接對磁碟進行對應的修改，因為對於磁碟IO實在是太慢了，我們首先會將修改的頁面（簡稱髒頁）鏈起來，就和free鍊錶差不多，就是一個基節點將對應臟頁的控制塊連接在一起。
這個flush鍊錶就代表我們即將還沒有將頁面更新到磁碟的鍊錶。
因為buffer pool的大小是有限的，所以我們對於快取頁的大小是有限的，所以我們需要將不使用的頁面進行一個淘汰。 MySQL採用的就是LRU的方式進行淘汰。
LRU就是最久未使用淘汰的策略，我們使用一個鍊錶將快取頁面鏈起來，最近訪問的出現在最前面，最久未訪問的在鍊錶末尾，當LRU滿了新頁面都進來機會淘汰鍊錶尾部頁面。
我們直接使用LRU，當MySQL進行預讀或全表掃描出現大量低頻頁面被讀進LRU鍊錶，會導致高頻的頁面直接被淘汰掉了，取而代之的是一些不常用的頁面。
MySQL優化器會將預期會被查詢造訪的頁面預先載入到記憶體buffer pool中，以便提高查詢效能。可以分為兩種：
線性預讀
#當讀取一個區的頁數超過系統變數innodb_read_ahead_threshold的值預設為56，也就是說當我們讀取一個區的頁面超過56頁，MySQL就會異步的讀取下一個區的所有頁面到記憶體中。
隨機預讀
如果buffer pool已經快取了某個區的13個頁面，不管是不是順序的，只要有13頁面快取了，就會觸發MySQL非同步讀取本區的所有頁面到MySQL中。系統變數innodb_random_read_ahead可以被設定為關閉隨機預讀。預設是OFF。
所以出現了改進基於分區的LRU鍊錶，將鍊錶分成兩份。
一個是使用頻率非常高的young區域，一個是使用頻率不是很高的old區。
正常来说old区占比是37％，所以young区就占63％，我们可以通过innodb_old_blocks_pct来修改，默认就是37。
我们来讲讲这个基于分区的LRU链表。
首先buffer pool初始化，会将读取的页面直接放进old区。
但是如果我们对于同一个页面的多条记录进行访问的话，我们就会多次访问同一页多次。但是如果我们是全表扫描的话，是可能会将所有页面缓存进缓存池中的，所以MySQL对于其进行优化。
所以MySQL对于当页面第一次读入old区并在一定时间间隔（innodb_old_blocks_pct）内的多次访问来说是不会将其放入young区进行缓存的。innodb_old_blocks_pct的值默认为1000，就是刚来的来一秒内的多次访问是不会将其转移到young区的。
如果多次访问就会将old区的页升级到young区。当young区的页面被访问，只有young链表后1/4的页面被访问时才会将其转置到young区链表头，不然就不会改动，减少一些调整链表的性能损失。
MySQL会启动后台线程进行脏页，也就是修改的页面进行刷新到磁盘。
以下有两种方式刷新脏页：
从LRU的尾部扫描一些页面，刷新其中的脏页到磁盘中。
在LRU链表的old区域尾部，即不经常使用的页面中，后台线程会查找是否存在脏页，如果有，则将其更新至磁盘。控制扫描区域尾部数量的方法是更改系统变量innodb_lru_scan_depth。
从flush链表中更新到磁盘。
我们上面说了flush连接这脏页的控制块，我们就可以将连接这flush链表的脏页进行更新。
疑问：为什么要两种方式更新呢？我刚开始不懂这是我回过头来看的时候就懂了
首先我们脏页是缓存在buffer pool中的，但是我们buffer pool空间是有限的，又因为我们使用的是LRU的方式，又因为从flush链表将脏页同步到磁盘效率实在不高，所以不会很经常去更新脏页。如果我们不更新直接将其从LRU的链表抛弃也就是从缓存池中直接扔了，但是它是脏页就无法同步到磁盘了，同时flush链表链接的也会出现问题。
所以在LRU淘汰很久未使用的页有个前提就是它不是一个脏页。为了淘汰这些页面，我们需要检查LRU链表的末尾是否存在脏页并进行更新。
flush链表更新那就是它的本职工作了，它存这个也是干这个的，应该没有什么问题。
当系统十分繁忙，buffer pool使用量不足的时候，因为磁盘IO太慢了，所以会出现一种情况，就是大量的用户线程也在进行这个同步脏页的活。如果未进行脏页同步并淘汰缓冲池的页面，则无法读取该页面。
我们可以设置多个buffer pool来实现多实例提高性能。
mysql> show variables like 'innodb_buffer_pool_instances'; +------------------------------+-------+ | Variable_name | Value | +------------------------------+-------+ | innodb_buffer_pool_instances | 1 | +------------------------------+-------+ 1 row in set, 1 warning (0.00 sec)
我们可以设置innodb_buffer_pool_instances系统变量来控制实例变量。
但是当buffer pool的大小小于1G的时候，设置2个实例也是没有用的（会被恢复成1个），多实例的情况是建立在大内存的情况下的。
在MySQL5.7.5后，MySQL中的buffer pool的大小是以chunk来分配了，如下图。
一个buffer pool是由多个chunk组成的，所以MySQL向操作系统申请连续的内存空间，就是以chunk的方式来申请的，这样我们可以在MySQL运行时调整buffer pool的大小。在运行时更改chunk大小不可行，并且会造成性能浪费。？
innodb_buffer_pool_size / innodb_buffer_pool_instances = 每个实例buffer pool的大小。
每个实例的大小 / innodb_buffer_pool_chunk_size = 每个实例由多少个chunk构成。
不是弄很明白，怎么动态调整大小，我调整了但是mysqld占用内存大小还是只能重启才能生效，我不会。
show engine innodb status;
以上是MySQL中讀頁緩衝區buffer pool的知識點有哪些的詳細內容。更多資訊請關注PHP中文網其他相關文章！
