一、頁的概覽

我們往 MySQL 插入的數(shù)據(jù)最終都是存在頁中的。在 InnoDB 中的設(shè)計中，頁與頁之間是通過一個雙向鏈表連接起來。

而存儲在頁中的一行一行的數(shù)據(jù)則是通過單鏈表連接起來的。

上圖中的 User Records 的區(qū)域就是用來存儲行數(shù)據(jù)的。那 InnoDB 為什么要這么設(shè)計？假設(shè)我們沒有頁這個概念，那么當我們查詢時，成千上萬的數(shù)據(jù)要如何做到快速的查詢出結(jié)果？眾所周知，MySQL 的性能是不錯的，而如果沒有頁，我們剩下的只能是逐條逐條的遍歷數(shù)據(jù)了。

那頁是如何做到快速查詢的呢？在當前頁中，可以通過 User Records 中的連接每條記錄的單鏈表來進行遍歷，如果在當前頁中沒有找到，則可以通過下一頁指針快速的跳到下一頁進行查詢。

二、Infimum 和 Supremum

有人可能會說了，你在 User Records 中還不是通過遍歷來解決的，你就是簡單的把數(shù)據(jù)分了個組而已。如果我的數(shù)據(jù)根本不在當前這個頁中，那我難道還是得把之前的頁中的每一條數(shù)據(jù)全部遍歷完？這效率也太低了

當然，MySQL 也考慮到了這個問題，所以實際上在頁中還存在一塊區(qū)域叫做 The Infimum and Supremum Records ，代表了當前頁中最大和最小的記錄。

有了 Infimum Record 和 Supremum Record ，現(xiàn)在查詢不需要將某一頁的 User Records 全部遍歷完，只需要將這兩個記錄和待查詢的目標記錄進行比較。比如我要查詢的數(shù)據(jù) id = 101 ，那很明顯不在當前頁。接下來就可以通過下一頁指針跳到下頁進行檢索。

三、使用Page Directory

可能有人又會說了，你這 User Records 里不也全是單鏈表嗎？即使我知道我要找的數(shù)據(jù)在當前頁，那最壞的情況下，不還是得挨個挨個的遍歷100次才能找到我要找的數(shù)據(jù)？你管這也叫效率高？

不得不說，這的確是個問題，不過是一個 MySQL 已經(jīng)考慮到的問題。不錯，挨個遍歷確實效率很低。為了解決這個問題，MySQL 又在頁中加入了另一個區(qū)域 Page Directory 。

顧名思義，Page Directory 是個目錄，里面有很多個槽位（Slots），每一個槽位都指向了一條 User Records 中的記錄。大家可以看到，每隔幾條數(shù)據(jù)，就會創(chuàng)建一個槽位。其實我圖中給出的數(shù)據(jù)是非常嚴格按照其設(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ù)進行粗略的二分查找。至于為什么是粗略，畢竟 Page Directory 中不是完整的數(shù)據(jù)，二分查找出來的結(jié)果只能是個大概的位置，找到了這個大概的位置之后，還需要回到 User Records 中繼續(xù)的進行挨個遍歷匹配。

不過這樣的效率已經(jīng)比我們剛開始聊的原始版本高了很多了。

四、頁的真實面貌

如果我開篇就把頁的各種組成部分，各種概念直接拋出來，首先我自己接受不了，這樣顯得很僵硬。其次，對頁不熟悉的人應(yīng)該是不太能理解頁為什么要這么設(shè)計的。所以我按照查詢一條數(shù)據(jù)的一套思路，把頁的大致的面貌呈現(xiàn)給了大家。

實際上，頁上還存儲了很多其他的字段，也還有其他的區(qū)域，但是這些都不會影響到我們對頁的理解。所以，在對頁有了一個較為清晰的認知之后，我們就可以來看看真實的頁到底長啥樣了。

上圖就是頁的實際全部組成，除了我們之前提到過的，還多了一些之前沒有聊過的，例如 File Header、Page Header、Free Space、File Tailer 。我們一個一個來看。

4.1、File Header

其實File Header 在上文已經(jīng)聊過了，只是不叫這個名字。上面提到的上一頁指針和下一頁指針其實就是屬于File Header的，除此之外還有很多其他的數(shù)據(jù)。

其實我比較抗拒把一堆參數(shù)列出來，告訴你這個大小多少，那個用來干嘛。對于我們需要詳細了解頁來說，其實暫時只需要知道兩個就足夠了，分別是：

• FIL_PAGE_PREV
• FIL_PAGE_NEXT

這兩個變量就是上文提到過的上一頁指針和下一頁指針，說是指針，是為了方便大家理解，實際上是頁在磁盤上的偏移量。

4.2、Page Header

比起 File Header ，Page Header 中的數(shù)據(jù)對我們來說就顯得更加熟悉了，我這里畫了一張圖，把里面的內(nèi)容詳細的列了出來。

這里全列出來是因為了解這些參數(shù)的含義和為什么要設(shè)置參數(shù)，能夠更好的幫助我們了解頁的原理和構(gòu)造，具體的看圖說話就行。

這里也很想吐槽，太多博客都寫的太僵硬，比如參數(shù) PAGE_HEAP_TOP ，這里的 HEAP 很多博客都直接叫堆。這就跟你給Init寫注釋叫初始化一樣，還不如不寫。實際上你去研究一下就會知道，這里的堆實際上就是指User Records。

里面有個兩個參數(shù)可能會有點混淆，分別是PAGE_N_HEAP和PAGE_N_RECS ，都是當前 User Records 中記錄的數(shù)量，唯一的不同在于，PAGE_N_HEAP 中是包含了被標記為刪除的記錄的， 而 PAGE_N_RECS 中就是實際上我們能夠查詢到的所有數(shù)據(jù)。

4.3、Infimum & Supremum Records

上文中提到，Infimum & Supremum Records會記錄當前頁最大最小記錄。實際上不準確，更準確的描述是最小記錄和最大紀錄的開區(qū)間。因為實際上 Infimum Records 會比當前頁中的最小值還要小，而 Supremum Records 會比當前頁中的最大值要大。

4.4、User Records

User 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)聊過了。這里只聊我認為很關(guān)鍵的一點，那就是順序。

我們知道，在聚簇索引中，Key 實際上會按照 Primary Key 的順序來進行排列。那在 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排列的順序。

用圖來表示，大概如下：

4.5、Free Space

這塊其實變相的在其他的模塊中討論了，最初 User Records 是完全空的，當有新數(shù)據(jù)進來時，會來 Free Space 中申請空間，當 Free Space 沒空間了，則說明需要申請新的頁了，其他沒什么特別之處。

4.6、Page Directory

這跟上文討論的沒什么出入，就直接跳過了。

4.7、File Trailer

這塊主要是為了防止頁在刷入磁盤的過程中，由于極端的意外情況（網(wǎng)絡(luò)問題、火災(zāi)、自然災(zāi)害）導(dǎo)致失敗，而造成數(shù)據(jù)不一致的情況，也就是說形成了臟頁。

里面有只有一個組成部分：

五、總結(jié)

到此，我認為關(guān)于頁的所有東西就聊的差不多了，了解了底層的頁原理，我個人認為是有助于我們更加友好、理智的使用 MySQL 的，使其能發(fā)揮出自己應(yīng)該發(fā)揮的極致性能。

以上就是淺談MySQL之淺入深出頁原理的詳細內(nèi)容，更多關(guān)于MySQL 頁原理的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論