MySQL 頁(yè)完全指南—淺入深出頁(yè)的原理

作者：SH的全棧筆記 2021-06-21 08:58:14

頁(yè)（Pages）是 InnoDB 中管理數(shù)據(jù)的最小單元。Buffer Pool 中存的就是一頁(yè)一頁(yè)的數(shù)據(jù)。再比如，當(dāng)我們要查詢的數(shù)據(jù)不在 Buffer Pool 中時(shí)，InnoDB 會(huì)將記錄所在的頁(yè)整個(gè)加載到 Buffer Pool 中去；同樣的，將 Buffer Pool 中的臟頁(yè)刷入磁盤時(shí)，也是按照頁(yè)為單位刷入磁盤的。

[[406472]]

之前寫了一些關(guān)于 MySQL 的 InnoDB 存儲(chǔ)引擎的文章，里面好幾次都提到了頁(yè)(Pages)這個(gè)概念，但是都只是簡(jiǎn)要的提了一下。例如之前在聊 InnoDB內(nèi)存結(jié)構(gòu) 時(shí)提到過，但當(dāng)時(shí)的重點(diǎn)是內(nèi)存架構(gòu)，就沒有展開深入。

我發(fā)現(xiàn)有好幾次都需要提到頁(yè)，那我就正好拿一篇來詳細(xì)的講講 InnoDB 中的頁(yè)。

頁(yè)是什么

首先，我們需要知道，頁(yè)(Pages)是 InnoDB 中管理數(shù)據(jù)的最小單元。Buffer Pool 中存的就是一頁(yè)一頁(yè)的數(shù)據(jù)。再比如，當(dāng)我們要查詢的數(shù)據(jù)不在 Buffer Pool 中時(shí)，InnoDB 會(huì)將記錄所在的頁(yè)整個(gè)加載到 Buffer Pool 中去;同樣的，將 Buffer Pool 中的臟頁(yè)刷入磁盤時(shí)，也是按照頁(yè)為單位刷入磁盤的。

不了解 Buffer Pool 的、或者感興趣的可以去文章開頭給的鏈接熟悉一下

頁(yè)的概覽

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

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

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

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

Infimum 和 Supremum

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

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

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

使用Page Directory

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

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

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

Page Directory 的設(shè)計(jì)不知道有沒有讓你想起另一個(gè)數(shù)據(jù)結(jié)構(gòu)——跳表，只不過這里只抽象了一層索引

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

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

頁(yè)的真實(shí)面貌

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

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

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

File Header

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

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

FIL_PAGE_PREV
FIL_PAGE_NEXT

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

Page Header

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

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

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

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

Infimum & Supremum Records

上文中提到，Infimum & Supremum Records會(huì)記錄當(dāng)前頁(yè)最大最小記錄。實(shí)際上不準(zhǔn)確，更準(zhǔn)確的描述是最小記錄和最大紀(jì)錄的開區(qū)間。因?yàn)閷?shí)際上 Infimum Records 會(huì)比當(dāng)前頁(yè)中的最小值還要小，而 Supremum Records 會(huì)比當(dāng)前頁(yè)中的最大值要大。

User Records

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

關(guān)于 User Records 中的概念，之前已經(jīng)聊過了。這里只聊我認(rèn)為很關(guān)鍵的一點(diǎn)，那就是順序。

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

答案是不會(huì)，因?yàn)檫@樣會(huì)拉低 MySQL 處理的效率。

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

用圖來表示，大概如下：

Free Space

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