淺談MySQL之淺入深出頁原理
一、頁的概覽
我們往 MySQL 插入的數據最終都是存在頁中的。在 InnoDB 中的設計中，頁與頁之間是通過一個雙向鏈表連接起來。
而存儲在頁中的一行一行的數據則是通過單鏈表連接起來的。
上圖中的 User Records 的區域就是用來存儲行數據的。那 InnoDB 為什麼要這麼設計？假設我們沒有頁這個概念，那麼當我們查詢時，成千上萬的數據要如何做到快速的查詢出結果？眾所周知，MySQL 的性能是不錯的，而如果沒有頁，我們剩下的隻能是逐條逐條的遍歷數據瞭。
那頁是如何做到快速查詢的呢？在當前頁中，可以通過 User Records 中的連接每條記錄的單鏈表來進行遍歷，如果在當前頁中沒有找到，則可以通過下一頁指針快速的跳到下一頁進行查詢。
二、Infimum 和 Supremum
有人可能會說瞭，你在 User Records 中還不是通過遍歷來解決的，你就是簡單的把數據分瞭個組而已。如果我的數據根本不在當前這個頁中，那我難道還是得把之前的頁中的每一條數據全部遍歷完？這效率也太低瞭
當然，MySQL 也考慮到瞭這個問題，所以實際上在頁中還存在一塊區域叫做 The Infimum and Supremum Records ，代表瞭當前頁中最大和最小的記錄。
有瞭 Infimum Record 和 Supremum Record ，現在查詢不需要將某一頁的 User Records 全部遍歷完，隻需要將這兩個記錄和待查詢的目標記錄進行比較。比如我要查詢的數據 id = 101 ，那很明顯不在當前頁。接下來就可以通過下一頁指針跳到下頁進行檢索。
三、使用Page Directory
可能有人又會說瞭，你這 User Records 裡不也全是單鏈表嗎？即使我知道我要找的數據在當前頁，那最壞的情況下，不還是得挨個挨個的遍歷100次才能找到我要找的數據？你管這也叫效率高？
不得不說，這的確是個問題，不過是一個 MySQL 已經考慮到的問題。不錯，挨個遍歷確實效率很低。為瞭解決這個問題，MySQL 又在頁中加入瞭另一個區域 Page Directory 。
顧名思義，Page Directory 是個目錄，裡面有很多個槽位（Slots），每一個槽位都指向瞭一條 User Records 中的記錄。大傢可以看到，每隔幾條數據，就會創建一個槽位。其實我圖中給出的數據是非常嚴格按照其設定來的，在一個完整的頁中，每隔6條數據就會有一個 Slot。
Page Directory 的設計不知道有沒有讓你想起另一個數據結構——跳表，隻不過這裡隻抽象瞭一層索引
MySQL 會在新增數據的時候就將對應的 Slot 創建好，有瞭 Page Directory ，就可以對一張頁的數據進行粗略的二分查找。至於為什麼是粗略，畢竟 Page Directory 中不是完整的數據，二分查找出來的結果隻能是個大概的位置，找到瞭這個大概的位置之後，還需要回到 User Records 中繼續的進行挨個遍歷匹配。
不過這樣的效率已經比我們剛開始聊的原始版本高瞭很多瞭。
四、頁的真實面貌
如果我開篇就把頁的各種組成部分，各種概念直接拋出來，首先我自己接受不瞭，這樣顯得很僵硬。其次，對頁不熟悉的人應該是不太能理解頁為什麼要這麼設計的。所以我按照查詢一條數據的一套思路，把頁的大致的面貌呈現給瞭大傢。
實際上，頁上還存儲瞭很多其他的字段，也還有其他的區域，但是這些都不會影響到我們對頁的理解。所以，在對頁有瞭一個較為清晰的認知之後，我們就可以來看看真實的頁到底長啥樣瞭。
上圖就是頁的實際全部組成，除瞭我們之前提到過的，還多瞭一些之前沒有聊過的，例如 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會記錄當前頁最大最小記錄。實際上不準確，更準確的描述是最小記錄和最大紀錄的開區間。因為實際上 Infimum Records 會比當前頁中的最小值還要小，而 Supremum Records 會比當前頁中的最大值要大。
4.4、User Records
User Records 可以說是我們平時接觸的最多的部分瞭，畢竟我們的數據最終都在這。頁被初始化之後，User Records 中是沒有數據的，隨著系統運行，數據產生，User Records 中的數據會不斷的膨脹，相應的 Free Space 空間會慢慢的變小。
關於 User Records 中的概念，之前已經聊過瞭。這裡隻聊我認為很關鍵的一點，那就是順序。
我們知道，在聚簇索引中，Key 實際上會按照 Primary Key 的順序來進行排列。那在 User Records 中也會這樣嗎？我們插入一條新的數據到 User Records 中時，是否也會按照 Primary Key 的順序來對已有的數據重排序？
答案是不會，因為這樣會拉低 MySQL 處理的效率。
User Records 中的數據是由單鏈表指針的指向來保證的，也就是說，行數據實際在磁盤上的表現，是按照插入順序來排隊的，先到的數據在前面，後來的數據在後面。隻不過通過 User Records 中的行數據之間的單鏈表形成瞭一個按照 Primary Key排列的順序。
用圖來表示，大概如下：
4.5、Free Space
這塊其實變相的在其他的模塊中討論瞭，最初 User Records 是完全空的，當有新數據進來時，會來 Free Space 中申請空間，當 Free Space 沒空間瞭，則說明需要申請新的頁瞭，其他沒什麼特別之處。
4.6、Page Directory
這跟上文討論的沒什麼出入，就直接跳過瞭。
4.7、File Trailer
這塊主要是為瞭防止頁在刷入磁盤的過程中，由於極端的意外情況（網絡問題、火災、自然災害）導致失敗，而造成數據不一致的情況，也就是說形成瞭臟頁。
裡面有隻有一個組成部分：
五、總結
到此，我認為關於頁的所有東西就聊的差不多瞭，瞭解瞭底層的頁原理，我個人認為是有助於我們更加友好、理智的使用 MySQL 的，使其能發揮出自己應該發揮的極致性能。
以上就是淺談MySQL之淺入深出頁原理的詳細內容，更多關於MySQL 頁原理的資料請關註WalkonNet其它相關文章！