Buffer pool
我們都知道,在讀取頁面時,需要先將頁面從磁碟讀取到記憶體中,然後等待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組成
每個頁面都包含其對應的控制塊訊息,這些訊息儲存在buffer pool中。每個控制塊對應管理每一個頁面 (我們使用地址引用每一個頁面) ,控制塊用來存儲頁面的一些信息,控制塊的佔用大小不包括在innodb_buffer_pool_size中。由MySQL在啟動時自行額外申請空間。
由於無法充分利用空間,控制區塊和快取頁之間會存在一些不規則的碎片。因為MySQL向作業系統申請的記憶體空間需要申請一定大小的控制區塊空間,無法確定具體的大小,難免回有無法利用的空間。
free鍊錶
free鍊錶顧名思義,就是管理空閒的快取頁面的鍊錶,如果快取頁沒有被使用,其控制區塊就會連接到free鍊錶上。
透過一個基底節點連接控制塊形成一個free鍊錶,並儲存空閒頁的數量等基本資訊。
當我們從磁碟讀取一個頁到buffer pool中,就會取一個空閒的控制區塊填入對應快取頁的基本資訊。
快取頁的雜湊處理
MySQL在buffer pool怎麼快速存取一個頁,以及看對應頁有沒有被快取到buffer pool呢?
這就是用到雜湊表,在Java中就是hashmap,透過表空間 頁號做處理形成一個hash的key值,然後value值就是快取頁在buffer pool中的位址。
flush鍊錶的管理
學習到這一章節的時候我震驚了,首先確實和我的理解是不一樣的,以及到後面的MVCC確實讓我大開眼界,這是我學習一遍後回頭的總結,所以比較言簡意賅哈。
我們使用SQL語句對某筆記錄進行修改的時候,就會修改某個頁面或多個頁面,我們對於頁面的修改呢,並不會直接對磁碟進行對應的修改,因為對於磁碟IO實在是太慢了,我們首先會將修改的頁面(簡稱髒頁)鏈起來,就和free鍊錶差不多,就是一個基節點將對應臟頁的控制塊連接在一起。
這個flush鍊錶就代表我們即將還沒有將頁面更新到磁碟的鍊錶。
LRU鍊錶
因為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实例
我们可以设置多个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个),多实例的情况是建立在大内存的情况下的。
动态调整buffer pool大小
在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占用内存大小还是只能重启才能生效,我不会。
查看buffer pool具体的信息
show engine innodb status;
以上是MySQL中讀頁緩衝區buffer pool的知識點有哪些的詳細內容。更多資訊請關注PHP中文網其他相關文章!

MySQL使用的是GPL許可證。 1)GPL許可證允許自由使用、修改和分發MySQL,但修改後的分發需遵循GPL。 2)商業許可證可避免公開修改,適合需要保密的商業應用。

選擇InnoDB而不是MyISAM的情況包括:1)需要事務支持,2)高並發環境,3)需要高數據一致性;反之,選擇MyISAM的情況包括:1)主要是讀操作,2)不需要事務支持。 InnoDB適合需要高數據一致性和事務處理的應用,如電商平台,而MyISAM適合讀密集型且無需事務的應用,如博客系統。

在MySQL中,外鍵的作用是建立表與表之間的關係,確保數據的一致性和完整性。外鍵通過引用完整性檢查和級聯操作維護數據的有效性,使用時需注意性能優化和避免常見錯誤。

MySQL中有四種主要的索引類型:B-Tree索引、哈希索引、全文索引和空間索引。 1.B-Tree索引適用於範圍查詢、排序和分組,適合在employees表的name列上創建。 2.哈希索引適用於等值查詢,適合在MEMORY存儲引擎的hash_table表的id列上創建。 3.全文索引用於文本搜索,適合在articles表的content列上創建。 4.空間索引用於地理空間查詢,適合在locations表的geom列上創建。

toCreateAnIndexinMysql,usethecReateIndexStatement.1)forasingLecolumn,使用“ createIndexIdx_lastNameEnemployees(lastName); 2)foracompositeIndex,使用“ createIndexIndexIndexIndexIndexDx_nameOmplayees(lastName,firstName,firstName);” 3)forauniqe instex,creationexexexexex,

MySQL和SQLite的主要區別在於設計理念和使用場景:1.MySQL適用於大型應用和企業級解決方案,支持高性能和高並發;2.SQLite適合移動應用和桌面軟件,輕量級且易於嵌入。

MySQL中的索引是數據庫表中一列或多列的有序結構,用於加速數據檢索。 1)索引通過減少掃描數據量提升查詢速度。 2)B-Tree索引利用平衡樹結構,適合範圍查詢和排序。 3)創建索引使用CREATEINDEX語句,如CREATEINDEXidx_customer_idONorders(customer_id)。 4)複合索引可優化多列查詢,如CREATEINDEXidx_customer_orderONorders(customer_id,order_date)。 5)使用EXPLAIN分析查詢計劃,避

在MySQL中使用事務可以確保數據一致性。 1)通過STARTTRANSACTION開始事務,執行SQL操作後用COMMIT提交或ROLLBACK回滾。 2)使用SAVEPOINT可以設置保存點,允許部分回滾。 3)性能優化建議包括縮短事務時間、避免大規模查詢和合理使用隔離級別。


熱AI工具

Undresser.AI Undress
人工智慧驅動的應用程序,用於創建逼真的裸體照片

AI Clothes Remover
用於從照片中去除衣服的線上人工智慧工具。

Undress AI Tool
免費脫衣圖片

Clothoff.io
AI脫衣器

Video Face Swap
使用我們完全免費的人工智慧換臉工具,輕鬆在任何影片中換臉!

熱門文章

熱工具

WebStorm Mac版
好用的JavaScript開發工具

Dreamweaver CS6
視覺化網頁開發工具

SAP NetWeaver Server Adapter for Eclipse
將Eclipse與SAP NetWeaver應用伺服器整合。

EditPlus 中文破解版
體積小,語法高亮,不支援程式碼提示功能

Safe Exam Browser
Safe Exam Browser是一個安全的瀏覽器環境,安全地進行線上考試。該軟體將任何電腦變成一個安全的工作站。它控制對任何實用工具的訪問,並防止學生使用未經授權的資源。