我們都知道,在讀取頁面時,需要先將頁面從磁碟讀取到記憶體中,然後等待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中文網其他相關文章!