Mysql 中數(shù)據(jù)是要落盤(pán)的,這點(diǎn)大家都知道。讀寫(xiě)磁盤(pán)速度是很慢的,尤其和內(nèi)存比起來(lái)更是沒(méi)的說(shuō)。但是,我們平時(shí)在執(zhí)行 SQL 時(shí),無(wú)論寫(xiě)操作還是讀操作都能很快得到結(jié)果,并沒(méi)有預(yù)想中的那么慢。
可能你會(huì)說(shuō)我有索引啊,有索引當(dāng)然快了。但是鐵子,索引文件也是存儲(chǔ)在磁盤(pán)上的,查找過(guò)程會(huì)產(chǎn)生磁盤(pán) I/O。如果同時(shí)對(duì)某行數(shù)據(jù)進(jìn)行多次操作,那豈不是要重復(fù)產(chǎn)生很多次磁盤(pán) IO 嗎?
可能你想到了,那我把數(shù)據(jù)存在內(nèi)存里不就可以了嗎??jī)?nèi)存速度比磁盤(pán)快,這準(zhǔn)沒(méi)毛病。沒(méi)錯(cuò),那該怎么存呢? 這就是我們今天所要講的主題——緩沖池(buffer pool)。
各位看官,請(qǐng)跟我來(lái)~
圖注:思維導(dǎo)圖
初識(shí)緩沖池
上邊我們提到過(guò)了,執(zhí)行 SQL 對(duì)某一行進(jìn)行操作時(shí),總不能每次都直接進(jìn)行磁盤(pán)操作吧。好歹有個(gè)緩沖地帶,不然每次都深入老巢這誰(shuí)受得了。
這不緩沖池就應(yīng)運(yùn)而生了,簡(jiǎn)單來(lái)說(shuō)就是一塊內(nèi)存區(qū)域。它存在的原因之一是為了避免每次都去訪問(wèn)磁盤(pán),把最常訪問(wèn)的數(shù)據(jù)放在緩存里,提高數(shù)據(jù)的訪問(wèn)速度。
了解了它的作用,接下來(lái)讓我們先來(lái)看下緩沖池在整個(gè) Mysql 架構(gòu)里處于什么樣的地方,有一個(gè)宏觀的認(rèn)識(shí)。
我們?cè)賮?lái)看看它的內(nèi)部組成部分。在緩沖池中,除數(shù)據(jù)頁(yè)和索引頁(yè)外還有多種類(lèi)型:
緩沖池的應(yīng)用
緩沖池你也了解了,可能此時(shí)你最關(guān)注的是它在 SQL 執(zhí)行時(shí)起了一個(gè)什么樣的作用。上篇文章中我們簡(jiǎn)單的提到過(guò)一條 SQL 語(yǔ)句的執(zhí)行過(guò)程,但并未涉及到緩沖池相關(guān)的問(wèn)題。這期我們?nèi)允且砸粭l SQL 來(lái)作為切入點(diǎn)。
當(dāng)一條 SQL 執(zhí)行的時(shí)候,如果是讀操作,要查找的數(shù)據(jù)所在的數(shù)據(jù)頁(yè)在內(nèi)存中時(shí),則將結(jié)果返回。否則會(huì)把對(duì)應(yīng)的數(shù)據(jù)頁(yè)加載到內(nèi)存中,然后再返回結(jié)果。
同樣對(duì)于寫(xiě)操作來(lái)說(shuō)。如果要修改的行所在的數(shù)據(jù)頁(yè)在內(nèi)存中,則修改后返回對(duì)應(yīng)的結(jié)果(當(dāng)然還有后續(xù)操作)。如果不在的話,則會(huì)從磁盤(pán)里將該行所對(duì)應(yīng)的數(shù)據(jù)頁(yè)讀到內(nèi)存中再進(jìn)行修改。
好了,現(xiàn)在讓我們回到開(kāi)始時(shí)候的問(wèn)題。為什么操作磁盤(pán)慢,但是 SQL 執(zhí)行卻不慢呢。到這里相信你也差不多知道了吧。
緩沖池的存在,很大程度減少了磁盤(pán) I/O 帶來(lái)的開(kāi)銷(xiāo)。要操作的數(shù)據(jù)行所在的數(shù)據(jù)頁(yè)如果存在于緩存中的話,就不需要從磁盤(pán)中進(jìn)行讀取。這樣在執(zhí)行后就可以很快拿到結(jié)果。
緩沖池的預(yù)讀機(jī)制
我們可以看出來(lái),只要不存在或減少磁盤(pán) I/O,執(zhí)行速度自然就會(huì)變快。那么對(duì)于加載數(shù)據(jù)頁(yè)這種無(wú)法避免的磁盤(pán) I/O 來(lái)說(shuō)是否有更好的方式呢?既然避免不了,那減少磁盤(pán) I/O 的次數(shù)總可以吧?
這就是我們要講的 Mysql 中「預(yù)讀」的新特性,它是 Innodb 通過(guò)在緩沖池中提前讀取多個(gè)數(shù)據(jù)頁(yè)來(lái)優(yōu)化 I/O 的一種方式。因?yàn)榇疟P(pán)讀寫(xiě)的時(shí)候,是按照頁(yè)的方式來(lái)讀取的(你可以理解為固定大小的數(shù)據(jù),例如一頁(yè)數(shù)據(jù)為 16K),每次至少讀入一頁(yè)的數(shù)據(jù),如果下次讀取的數(shù)據(jù)就在頁(yè)中,就不用再去磁盤(pán)上讀取了,從而減少了磁盤(pán) I/O。
可以在命令行通過(guò)如下命令查看對(duì)應(yīng)的頁(yè)大小:
緩沖池的空間管理
你可能會(huì)有疑問(wèn),緩沖池這么洋氣的東西,為什么不把所有的數(shù)據(jù)都放到緩沖池里呢?這樣速度豈不是美滋滋,放到磁盤(pán)里慢的跟老牛拉車(chē)一樣。
哎,哥,醒醒,拋開(kāi)內(nèi)存的易失性不談,緩沖池也是有大小限制的。那你可能又有疑惑了,既然緩沖池有大小限制,那我每次都讀入的數(shù)據(jù)頁(yè)怎么來(lái)管理呢。別的數(shù)據(jù)頁(yè)都占了地兒了,哪有我的位置?
這里我們來(lái)聊聊緩沖池的空間管理,其實(shí)對(duì)緩沖池進(jìn)行管理的關(guān)鍵部分是如何安排進(jìn)池的數(shù)據(jù)并且按照一定的策略淘汰池中的數(shù)據(jù),保證池中的數(shù)據(jù)不“溢出”,同時(shí)還能保證常用數(shù)據(jù)留在池子中。
傳統(tǒng) LRU 淘汰法
緩沖池是基于傳統(tǒng)的 LRU 方法來(lái)進(jìn)行緩存頁(yè)管理的,我們先來(lái)看下如果使用 LRU 是如何管理的。
LRU,全稱(chēng)是 Least Recently Used,中文名字叫作「最近最少使用」。從名字上就很容易理解了。
這里分兩種情況:
(1)緩存頁(yè)已在緩沖池中
這種情況下會(huì)將對(duì)應(yīng)的緩存頁(yè)放到 LRU 鏈表的頭部,無(wú)需從磁盤(pán)再進(jìn)行讀取,也無(wú)需淘汰其它緩存頁(yè)。
如下圖所示,如果要訪問(wèn)的數(shù)據(jù)在 6 號(hào)頁(yè)中,則將 6 號(hào)頁(yè)放到鏈表頭部即可,這種情況下沒(méi)有緩存頁(yè)被淘汰。
(2)緩存頁(yè)不在緩沖池中
緩存頁(yè)不在緩沖中,這時(shí)候就需要從磁盤(pán)中讀入對(duì)應(yīng)的數(shù)據(jù)頁(yè),將其放置在鏈表頭部,同時(shí)淘汰掉末尾的緩存頁(yè)
如下圖所示,如果要訪問(wèn)的數(shù)據(jù)在 60 號(hào)頁(yè)中,60 號(hào)頁(yè)不在緩沖池中,此時(shí)加載進(jìn)來(lái)放到鏈表的頭部,同時(shí)淘汰掉末尾的 17 號(hào)緩存頁(yè)。
是不是看上去很簡(jiǎn)單,同時(shí)也能滿足緩沖池淘汰緩存頁(yè)的方法?但是我們來(lái)思考幾個(gè)問(wèn)題:
預(yù)讀失效
上面我們提到了緩沖池的預(yù)讀機(jī)制可能會(huì)預(yù)先加載相鄰的數(shù)據(jù)頁(yè)。假如加載了 20、21 相鄰的兩個(gè)數(shù)據(jù)頁(yè),如果只有頁(yè)號(hào)為 20 的緩存頁(yè)被訪問(wèn)了,而另一個(gè)緩存頁(yè)卻沒(méi)有被訪問(wèn)。此時(shí)兩個(gè)緩存頁(yè)都在鏈表的頭部,但是為了加載這兩個(gè)緩存頁(yè)卻淘汰了末尾的緩存頁(yè),而被淘汰的緩存頁(yè)卻是經(jīng)常被訪問(wèn)的。這種情況就是預(yù)讀失效,被預(yù)先加載進(jìn)緩沖池的頁(yè),并沒(méi)有被訪問(wèn)到,這種情況是不是很不合理。
緩沖池污染
還有一種情況是當(dāng)執(zhí)行一條 SQL 語(yǔ)句時(shí),如果掃描了大量數(shù)據(jù)或是進(jìn)行了全表掃描,此時(shí)緩沖池中就會(huì)加載大量的數(shù)據(jù)頁(yè),從而將緩沖池中已存在的所有頁(yè)替換出去,這種情況同樣是不合理的。這就是緩沖池污染,并且還會(huì)導(dǎo)致 MySQL 性能急劇下降。
冷熱數(shù)據(jù)分離
這樣看來(lái),傳統(tǒng)的 LRU 方法并不能滿足緩沖池的空間管理。因此,Msyql 基于 LRU 設(shè)計(jì)了冷熱數(shù)據(jù)分離的處理方案。
也就是將 LRU 鏈表分為兩部分,一部分為熱數(shù)據(jù)區(qū)域,一部分為冷數(shù)據(jù)區(qū)域。
當(dāng)數(shù)據(jù)頁(yè)第一次被加載到緩沖池中的時(shí)候,先將其放到冷數(shù)據(jù)區(qū)域的鏈表頭部,1s(由 innodb_old_blocks_time 參數(shù)控制) 后該緩存頁(yè)被訪問(wèn)了再將其移至熱數(shù)據(jù)區(qū)域的鏈表頭部。
可能你會(huì)有疑惑了,為什么要等 1s 后才將其移至熱數(shù)據(jù)區(qū)域呢?你想想,如果數(shù)據(jù)頁(yè)剛被加載到冷數(shù)據(jù)區(qū)就被訪問(wèn)了,之后再也不訪問(wèn)它了呢?這不就造成熱數(shù)據(jù)區(qū)的浪費(fèi)了嗎?要是 1s 后不訪問(wèn)了,說(shuō)明之后可能也不會(huì)去頻繁訪問(wèn)它,也就沒(méi)有移至熱緩沖區(qū)的必要了。當(dāng)緩存頁(yè)不夠的時(shí)候,從冷數(shù)據(jù)區(qū)淘汰它們就行了。
另一種情況,當(dāng)我的數(shù)據(jù)頁(yè)已經(jīng)在熱緩沖區(qū)了,是不是緩存頁(yè)只要被訪問(wèn)了就將其插到鏈表頭部呢?不用我說(shuō)你肯定也覺(jué)得不合理。熱數(shù)據(jù)區(qū)域里的緩存頁(yè)是會(huì)被經(jīng)常訪問(wèn)的,如果每訪問(wèn)一個(gè)緩存頁(yè)就插入一次鏈表頭,那整個(gè)熱緩沖區(qū)里就異常騷動(dòng)了,你想想那個(gè)畫(huà)面。
那咋整呢?Mysql 中優(yōu)化為熱數(shù)據(jù)區(qū)的后 3/4 部分被訪問(wèn)后才將其移動(dòng)到鏈表頭部去,對(duì)于前 1/4 部分的緩存頁(yè)被訪問(wèn)了不會(huì)進(jìn)行移動(dòng)。
好了,到這里關(guān)于 buffer pool 的知識(shí)就講完了。這期里我們講了 buffer pool 能使 SQL 執(zhí)行變快的原因,同時(shí)還講了有關(guān) buffer pool 空間的管理方式。歡迎在留言區(qū)里進(jìn)行討論。
總結(jié)
緩沖池的應(yīng)用
緩沖池很大程度減少了磁盤(pán) I/O 帶來(lái)的開(kāi)銷(xiāo),通過(guò)將操作的數(shù)據(jù)行所在的數(shù)據(jù)頁(yè)加載到緩沖池可以提高 SQL 的執(zhí)行速度。
緩沖池的預(yù)讀機(jī)制
為了減少磁盤(pán) I/O,Innodb 通過(guò)在緩沖池中提前讀取多個(gè)數(shù)據(jù)頁(yè)來(lái)進(jìn)行優(yōu)化,這種方式叫作預(yù)讀。
緩沖池的空間管理
- 傳統(tǒng)的LRU方法對(duì)于緩沖池來(lái)說(shuō),會(huì)導(dǎo)致預(yù)讀失效和緩沖池污染兩種情況,因此這種傳統(tǒng)的方式并不適用緩沖池的空間管理。
- 基于對(duì) LRU 方法的優(yōu)化,Msyql 設(shè)計(jì)了冷熱數(shù)據(jù)分離的處理方案,將LRU鏈表分為熱數(shù)據(jù)區(qū)和冷數(shù)據(jù)區(qū)兩部分,這樣就可以解決預(yù)讀失效和緩沖池污染的情況。
以上就是詳解MySQL中的緩沖池(buffer pool)的詳細(xì)內(nèi)容,更多關(guān)于MySQL 緩沖池(buffer pool)的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章!
您可能感興趣的文章:- MySQL Innodb關(guān)鍵特性之插入緩沖(insert buffer)
- MySQL的查詢(xún)緩存和Buffer Pool
- mysql優(yōu)化的重要參數(shù) key_buffer_size table_cache
- 優(yōu)化mysql之key_buffer_size設(shè)置
- mysql read_buffer_size 設(shè)置多少合適
- mysql Sort aborted: Out of sort memory, consider increasing server sort buffer size的解決方法
- 從MySQL的源碼剖析Innodb buffer的命中率計(jì)算
- php中mysql操作buffer用法詳解
- Mysql優(yōu)化調(diào)優(yōu)中兩個(gè)重要參數(shù)table_cache和key_buffer
- mysql Key_buffer_size參數(shù)的優(yōu)化設(shè)置
- mysqldump造成Buffer Pool污染的研究
- MySQL的join buffer原理