本篇內(nèi)容介紹了“如何理解MySQL的Buffer Pool”的有關知識,在實際案例的操作過程中,不少人都會遇到這樣的困境,接下來就讓小編帶領大家學習一下如何處理這些情況吧!希望大家仔細閱讀,能夠?qū)W有所成!
創(chuàng)新互聯(lián)專業(yè)為企業(yè)提供鐵嶺網(wǎng)站建設、鐵嶺做網(wǎng)站、鐵嶺網(wǎng)站設計、鐵嶺網(wǎng)站制作等企業(yè)網(wǎng)站建設、網(wǎng)頁設計與制作、鐵嶺企業(yè)網(wǎng)站模板建站服務,十載鐵嶺做網(wǎng)站經(jīng)驗,不只是建網(wǎng)站,更提供有價值的思路和整體網(wǎng)絡服務。
前言
buffer pool是什么
咱們在使用mysql的時候,比如很簡單的select * from table;這條語句,具體查詢數(shù)據(jù)其實是在存儲引擎中實現(xiàn)的,大家都知道m(xù)ysql數(shù)據(jù)其實是放在磁盤里面的,如果每次查詢都直接從磁盤里面查詢,這樣勢必會很影響性能,所以一定是先把數(shù)據(jù)從磁盤中取出,然后放在內(nèi)存中,下次查詢直接從內(nèi)存中來取。但是一臺機器中往往不是只有mysql一個進程在運行的,很多個進程都需要使用內(nèi)存,所以mysql中會有一個專門的區(qū)域來處理這些數(shù)據(jù),這個專門為mysql準備的區(qū)域,就叫buffer pool。
buffer pool的工作流程
咱們以查詢語句為例 1:在查詢的時候會先去buffer pool(內(nèi)存)中看看有沒有對應的數(shù)據(jù)頁,如果有的話直接返回 2:如果buffer pool中沒有對應的數(shù)據(jù)頁,則會去磁盤中查找,磁盤中如果找到了對應的數(shù)據(jù),則會把該頁的數(shù)據(jù)直接copy一份到buffer pool中返回給客戶端 3:下次有同樣的查詢進來直接查找buffer pool找到對應的數(shù)據(jù)返回即可。
大家看到這里相信應該對buffer pool有了個大概的認識,有沒有感覺有點緩存的感覺,當然buffer pool可沒有緩存那么簡單,內(nèi)部結(jié)構(gòu)還是比較復雜的,不過沒關系,咱們繼續(xù)往下看。
buffer pool數(shù)據(jù)管理
數(shù)據(jù)管理的基本單位
buffer pool畢竟是一種內(nèi)存管理,數(shù)據(jù)當然不是按照一條一條的sql語句來管理的,而是按照數(shù)據(jù)頁來管理的,innodb 引擎默認的數(shù)據(jù)頁是16kb,而buffer pool啟動的時候是默認的128M,所以是有8192個數(shù)據(jù)頁的。而磁盤的數(shù)據(jù)管理也是用數(shù)據(jù)頁為單位來管理的,所以每次查找數(shù)據(jù)的時候,先請求buffer pool,buffer pool中沒有的話會到磁盤中找到對應的數(shù)據(jù)頁,然后copy到buffer pool中給客戶端返回。
free鏈表
正常情況下,buffer pool肯定是從第一個數(shù)據(jù)頁,不斷的往后填充的,一個一個的往后寫入,每次直接在后面追加就可以了。如下圖(黃色部分表示已經(jīng)寫入數(shù)據(jù))
但是實際生產(chǎn)環(huán)境中,并不是這樣的,我們不光有查詢操作,還有刪除,修改等操作,而且已經(jīng)寫入buffer pool的數(shù)據(jù)不一定是始終有價值的,有一些數(shù)據(jù)是不需要的,需要釋放對應的數(shù)據(jù)頁的,所以就會造成buffer pool的數(shù)據(jù)其實是這種情況,間斷不連續(xù)的。
在這種情況下該如何去找到有效的空閑的數(shù)據(jù)頁空間來存儲數(shù)據(jù)呢?最直觀的方法就是從第一個頁遍歷的一個一個的往后找,找到空閑的數(shù)據(jù)頁即可,這種方法倒是可行,但是非常影響效率,所以mysql在處理這種問題用上了free鏈表的方式來管理空閑的數(shù)據(jù)頁。
大家可以看一看free鏈表的結(jié)構(gòu)
free鏈表有一個基節(jié)點,記錄了該free鏈表的唯一標志,該鏈表的尾節(jié)點地址,以及鏈表的總長度
基節(jié)點后面會有很多的控制塊,控制塊本身很小,只是存儲了指向空閑數(shù)據(jù)頁的指針而已,所以buffer pool在尋找空閑數(shù)據(jù)頁的時候直接用free鏈表可以直接找到。
只要有一頁數(shù)據(jù)空閑出來之后,直接把該數(shù)據(jù)頁的地址追加到free鏈表即可。
flush鏈表
當然只是用free鏈表是解決不了所有問題的,比如:我們在執(zhí)行update table test set field_a = 1;的時候,我們是先修改buffer pool里面對應的數(shù)據(jù)頁,然后再更新磁盤中對應的數(shù)據(jù)頁的,(當然這里會涉及到一個數(shù)據(jù)一致性的問題,mysql是用redo log解決的,這個不在咱們這篇文章的討論范圍之內(nèi))我們把buffer pool中對應修改的數(shù)據(jù)頁同步修改到磁盤的時候,這個過程稱之為"刷臟",刷臟是有一定策略的,可以用
select @@innodb_flush_log_at_trx_commit;
來查看刷臟策略
我們一般都不會設置實時寫,這樣很影響性能,所以一般都是延遲寫的,那么就會引發(fā)一個問題,mysql是如何在buffer pool中找到被修改過的臟數(shù)據(jù)的呢?這里咱們就用上了flush鏈表了,其實和free鏈表比較像
flush鏈表上面維護的都是臟數(shù)據(jù)頁的指針。刷臟的時候直接遍歷flush鏈表去刷臟就可以了。
lru鏈表
buffer pool是有一定空間限制的,默認是128M,總會有空間塞滿的時候的,所以數(shù)據(jù)頁是有淘汰機制的,淘汰機制就是lru(最近最少使用)。
lru原理其實也很簡單,使用到過的數(shù)據(jù)頁,直接移動到鏈表的頭部,然后在buffer pool滿了之后直接淘汰掉鏈表尾部的數(shù)據(jù)頁就可以了。
lru鏈表的優(yōu)化
其實簡單的lru鏈表是存在一定的問題的,比如咱們在工作過程中,可能會用上 select * from test這樣的語句來進行一些刷數(shù)據(jù)等需求,如果test表是非常大的,很有可能一下子把buffer pool占滿,把之前的數(shù)據(jù)頁全部都淘汰掉,然后其余的數(shù)據(jù)在線上業(yè)務正常執(zhí)行的時候,又會回來重新把之前select * from test 占用的數(shù)據(jù)頁重新慢慢淘汰掉,這一來一去是非常影響線上的性能的。
所以鑒于以上所在的問題,mysql的buffer pool是在lru的基礎上進行了一些優(yōu)化的。
buffer pool的lru鏈表把數(shù)據(jù)分為了熱數(shù)據(jù)塊和冷數(shù)據(jù)塊,比例大概5:3的樣子,每次新的數(shù)據(jù)頁寫入都會寫入冷數(shù)據(jù)區(qū)。
但是如果這樣的話那么熱數(shù)據(jù)區(qū)永遠都不會有數(shù)據(jù),所以冷數(shù)據(jù)區(qū)寫入的時候會另外記錄上寫入的時間,下次訪問該數(shù)據(jù)區(qū)的時候如果時間間隔大于1s,那么就會放入熱數(shù)據(jù)區(qū),這樣就不會淘汰掉大量的無辜數(shù)據(jù)。所以我們在執(zhí)行select * from test這種語句刷新腳本的時候,只會占用冷數(shù)據(jù)的空間,而不會影響到熱數(shù)據(jù)。
“如何理解MySQL的Buffer Pool”的內(nèi)容就介紹到這里了,感謝大家的閱讀。如果想了解更多行業(yè)相關的知識可以關注創(chuàng)新互聯(lián)網(wǎng)站,小編將為大家輸出更多高質(zhì)量的實用文章!