一、頁的概覽

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

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

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

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

二、Infimum 和 Supremum

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

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

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

三、使用Page Directory

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

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

顧名思義，Page Directory 是個目錄，里面有很多個槽位（Slots），每一個槽位都指向了一條 User Records 中的記錄。大家可以看到，每隔幾條數據，就會創(chuàng)建一個槽位。其實我圖中給出的數據是非常嚴格按照其設定來的，在一個完整的頁中，每隔6條數據就會有一個 Slot。

Page Directory 的設計不知道有沒有讓你想起另一個數據結構——跳表，只不過這里只抽象了一層索引

MySQL 會在新增數據的時候就將對應的 Slot 創(chuàng)建好，有了 Page Directory ，就可以對一張頁的數據進行粗略的二分查找。至于為什么是粗略，畢竟 Page Directory 中不是完整的數據，二分查找出來的結果只能是個大概的位置，找到了這個大概的位置之后，還需要回到 User Records 中繼續(xù)的進行挨個遍歷匹配。

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

四、頁的真實面貌

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

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

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

4.1、File Header

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

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

• FIL_PAGE_PREV
• FIL_PAGE_NEXT

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

4.2、Page Header

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

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

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

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

4.3、Infimum & Supremum Records

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

4.4、User Records

User Records 可以說是我們平時接觸的最多的部分了，畢竟我們的數據最終都在這。頁被初始化之后，User Records 中是沒有數據的，隨著系統(tǒng)運行，數據產生，User Records 中的數據會不斷的膨脹，相應的 Free Space 空間會慢慢的變小。

關于 User Records 中的概念，之前已經聊過了。這里只聊我認為很關鍵的一點，那就是順序。

我們知道，在聚簇索引中，Key 實際上會按照 Primary Key 的順序來進行排列。那在 User Records 中也會這樣嗎？我們插入一條新的數據到 User Records 中時，是否也會按照 Primary Key 的順序來對已有的數據重排序？

答案是不會，因為這樣會拉低 MySQL 處理的效率。

User Records 中的數據是由單鏈表指針的指向來保證的，也就是說，行數據實際在磁盤上的表現(xiàn)，是按照插入順序來排隊的，先到的數據在前面，后來的數據在后面。只不過通過 User Records 中的行數據之間的單鏈表形成了一個按照 Primary Key排列的順序。

用圖來表示，大概如下：

4.5、Free Space

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

4.6、Page Directory

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

4.7、File Trailer

這塊主要是為了防止頁在刷入磁盤的過程中，由于極端的意外情況（網絡問題、火災、自然災害）導致失敗，而造成數據不一致的情況，也就是說形成了臟頁。

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

五、總結

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

以上就是淺談MySQL之淺入深出頁原理的詳細內容，更多關于MySQL 頁原理的資料請關注本站其它相關文章！

海外服務器租用

版權聲明：本站文章來源標注為YINGSOO的內容版權均為本站所有，歡迎引用、轉載，請保持原文完整并注明來源及原文鏈接。禁止復制或仿造本網站，禁止在非www.sddonglingsh.com所屬的服務器上建立鏡像，否則將依法追究法律責任。本站部分內容來源于網友推薦、互聯(lián)網收集整理而來，僅供學習參考，不代表本站立場，如有內容涉嫌侵權，請聯(lián)系alex-e#qq.com處理。