淺談MySQL之淺入深出頁原理
我們往 MySQL 插入的數(shù)據(jù)最終都是存在頁中的。在 InnoDB 中的設(shè)計中,頁與頁之間是通過一個雙向鏈表連接起來。
而存儲在頁中的一行一行的數(shù)據(jù)則是通過單鏈表連接起來的。
上圖中的 User Records 的區(qū)域就是用來存儲行數(shù)據(jù)的。那 InnoDB 為什么要這么設(shè)計?假設(shè)我們沒有頁這個概念,那么當(dāng)我們查詢時,成千上萬的數(shù)據(jù)要如何做到快速的查詢出結(jié)果?眾所周知,MySQL 的性能是不錯的,而如果沒有頁,我們剩下的只能是逐條逐條的遍歷數(shù)據(jù)了。
那頁是如何做到快速查詢的呢?在當(dāng)前頁中,可以通過 User Records 中的連接每條記錄的單鏈表來進(jìn)行遍歷,如果在當(dāng)前頁中沒有找到,則可以通過下一頁指針快速的跳到下一頁進(jìn)行查詢。
二、Infimum 和 Supremum有人可能會說了,你在 User Records 中還不是通過遍歷來解決的,你就是簡單的把數(shù)據(jù)分了個組而已。如果我的數(shù)據(jù)根本不在當(dāng)前這個頁中,那我難道還是得把之前的頁中的每一條數(shù)據(jù)全部遍歷完?這效率也太低了
當(dāng)然,MySQL 也考慮到了這個問題,所以實際上在頁中還存在一塊區(qū)域叫做 The Infimum and Supremum Records ,代表了當(dāng)前頁中最大和最小的記錄。
有了 Infimum Record 和 Supremum Record ,現(xiàn)在查詢不需要將某一頁的 User Records 全部遍歷完,只需要將這兩個記錄和待查詢的目標(biāo)記錄進(jìn)行比較。比如我要查詢的數(shù)據(jù) id = 101 ,那很明顯不在當(dāng)前頁。接下來就可以通過下一頁指針跳到下頁進(jìn)行檢索。
三、使用Page Directory可能有人又會說了,你這 User Records 里不也全是單鏈表嗎?即使我知道我要找的數(shù)據(jù)在當(dāng)前頁,那最壞的情況下,不還是得挨個挨個的遍歷100次才能找到我要找的數(shù)據(jù)?你管這也叫效率高?
不得不說,這的確是個問題,不過是一個 MySQL 已經(jīng)考慮到的問題。不錯,挨個遍歷確實效率很低。為了解決這個問題,MySQL 又在頁中加入了另一個區(qū)域 Page Directory 。
顧名思義,Page Directory 是個目錄,里面有很多個槽位(Slots),每一個槽位都指向了一條 User Records 中的記錄。大家可以看到,每隔幾條數(shù)據(jù),就會創(chuàng)建一個槽位。其實我圖中給出的數(shù)據(jù)是非常嚴(yán)格按照其設(shè)定來的,在一個完整的頁中,每隔6條數(shù)據(jù)就會有一個 Slot。
Page Directory 的設(shè)計不知道有沒有讓你想起另一個數(shù)據(jù)結(jié)構(gòu)——跳表,只不過這里只抽象了一層索引
MySQL 會在新增數(shù)據(jù)的時候就將對應(yīng)的 Slot 創(chuàng)建好,有了 Page Directory ,就可以對一張頁的數(shù)據(jù)進(jìn)行粗略的二分查找。至于為什么是粗略,畢竟 Page Directory 中不是完整的數(shù)據(jù),二分查找出來的結(jié)果只能是個大概的位置,找到了這個大概的位置之后,還需要回到 User Records 中繼續(xù)的進(jìn)行挨個遍歷匹配。
不過這樣的效率已經(jīng)比我們剛開始聊的原始版本高了很多了。
如果我開篇就把頁的各種組成部分,各種概念直接拋出來,首先我自己接受不了,這樣顯得很僵硬。其次,對頁不熟悉的人應(yīng)該是不太能理解頁為什么要這么設(shè)計的。所以我按照查詢一條數(shù)據(jù)的一套思路,把頁的大致的面貌呈現(xiàn)給了大家。
實際上,頁上還存儲了很多其他的字段,也還有其他的區(qū)域,但是這些都不會影響到我們對頁的理解。所以,在對頁有了一個較為清晰的認(rèn)知之后,我們就可以來看看真實的頁到底長啥樣了。
上圖就是頁的實際全部組成,除了我們之前提到過的,還多了一些之前沒有聊過的,例如 File Header、Page Header、Free Space、File Tailer 。我們一個一個來看。
4.1、File Header其實File Header 在上文已經(jīng)聊過了,只是不叫這個名字。上面提到的上一頁指針和下一頁指針其實就是屬于File Header的,除此之外還有很多其他的數(shù)據(jù)。
其實我比較抗拒把一堆參數(shù)列出來,告訴你這個大小多少,那個用來干嘛。對于我們需要詳細(xì)了解頁來說,其實暫時只需要知道兩個就足夠了,分別是:
FIL_PAGE_PREV FIL_PAGE_NEXT這兩個變量就是上文提到過的上一頁指針和下一頁指針,說是指針,是為了方便大家理解,實際上是頁在磁盤上的偏移量。
4.2、Page Header比起 File Header ,Page Header 中的數(shù)據(jù)對我們來說就顯得更加熟悉了,我這里畫了一張圖,把里面的內(nèi)容詳細(xì)的列了出來。
這里全列出來是因為了解這些參數(shù)的含義和為什么要設(shè)置參數(shù),能夠更好的幫助我們了解頁的原理和構(gòu)造,具體的看圖說話就行。
這里也很想吐槽,太多博客都寫的太僵硬,比如參數(shù) PAGE_HEAP_TOP ,這里的 HEAP 很多博客都直接叫堆。這就跟你給Init寫注釋叫初始化一樣,還不如不寫。實際上你去研究一下就會知道,這里的堆實際上就是指User Records。
里面有個兩個參數(shù)可能會有點混淆,分別是PAGE_N_HEAP和PAGE_N_RECS ,都是當(dāng)前 User Records 中記錄的數(shù)量,唯一的不同在于,PAGE_N_HEAP 中是包含了被標(biāo)記為刪除的記錄的, 而 PAGE_N_RECS 中就是實際上我們能夠查詢到的所有數(shù)據(jù)。
4.3、Infimum & Supremum Records上文中提到,Infimum & Supremum Records會記錄當(dāng)前頁最大最小記錄。實際上不準(zhǔn)確,更準(zhǔn)確的描述是最小記錄和最大紀(jì)錄的開區(qū)間。因為實際上 Infimum Records 會比當(dāng)前頁中的最小值還要小,而 Supremum Records 會比當(dāng)前頁中的最大值要大。
4.4、User RecordsUser Records 可以說是我們平時接觸的最多的部分了,畢竟我們的數(shù)據(jù)最終都在這。頁被初始化之后,User Records 中是沒有數(shù)據(jù)的,隨著系統(tǒng)運行,數(shù)據(jù)產(chǎn)生,User Records 中的數(shù)據(jù)會不斷的膨脹,相應(yīng)的 Free Space 空間會慢慢的變小。
關(guān)于 User Records 中的概念,之前已經(jīng)聊過了。這里只聊我認(rèn)為很關(guān)鍵的一點,那就是順序。
我們知道,在聚簇索引中,Key 實際上會按照 Primary Key 的順序來進(jìn)行排列。那在 User Records 中也會這樣嗎?我們插入一條新的數(shù)據(jù)到 User Records 中時,是否也會按照 Primary Key 的順序來對已有的數(shù)據(jù)重排序?
答案是不會,因為這樣會拉低 MySQL 處理的效率。
User Records 中的數(shù)據(jù)是由單鏈表指針的指向來保證的,也就是說,行數(shù)據(jù)實際在磁盤上的表現(xiàn),是按照插入順序來排隊的,先到的數(shù)據(jù)在前面,后來的數(shù)據(jù)在后面。只不過通過 User Records 中的行數(shù)據(jù)之間的單鏈表形成了一個按照 Primary Key排列的順序。
用圖來表示,大概如下:
這塊其實變相的在其他的模塊中討論了,最初 User Records 是完全空的,當(dāng)有新數(shù)據(jù)進(jìn)來時,會來 Free Space 中申請空間,當(dāng) Free Space 沒空間了,則說明需要申請新的頁了,其他沒什么特別之處。
4.6、Page Directory這跟上文討論的沒什么出入,就直接跳過了。
4.7、File Trailer這塊主要是為了防止頁在刷入磁盤的過程中,由于極端的意外情況(網(wǎng)絡(luò)問題、火災(zāi)、自然災(zāi)害)導(dǎo)致失敗,而造成數(shù)據(jù)不一致的情況,也就是說形成了臟頁。
里面有只有一個組成部分:
到此,我認(rèn)為關(guān)于頁的所有東西就聊的差不多了,了解了底層的頁原理,我個人認(rèn)為是有助于我們更加友好、理智的使用 MySQL 的,使其能發(fā)揮出自己應(yīng)該發(fā)揮的極致性能。
以上就是淺談MySQL之淺入深出頁原理的詳細(xì)內(nèi)容,更多關(guān)于MySQL 頁原理的資料請關(guān)注好吧啦網(wǎng)其它相關(guān)文章!
相關(guān)文章:
