堆與聚集索引全表掃描

Question

我一直在為此來回搜索，但無法了解磁盤上的表數據塊的結構。

許多資源 state 執行全表掃描順序讀取塊（這意味着數據庫能夠一次讀取多個塊），但我找不到任何資源實際描述塊在磁盤上的保存方式堆 VS 聚集索引的情況。

堆不決定順序，這是因為數據庫不關心它從磁盤讀取的塊的順序，但是：

1. 我仍然沒有找到任何證據可以保證堆數據按順序存儲在磁盤上
2. 使用聚集索引，結果的順序確實很重要。 在那種情況下，我無法理解數據庫如何在保持順序的同時保持順序。 順序讀取是否仍然適用於聚集索引？

任何描述在每種情況下如何在磁盤上布置塊的資源都會有所幫助

Answer 1

您詢問了 MySQL，這通常是指默認的 InnoDB 存儲引擎。

InnoDB 不將表存儲為堆。

InnoDB 表始終存儲為聚集索引，其中聚集索引是主鍵。 因此，表掃描或多或少等同於聚集索引的索引掃描。

InnoDB 中的任何索引通常不會按順序存儲在磁盤上。 它存儲為頁面集合，其中頁面的統一大小為 16KB。 索引顯然比這大得多，隨着時間的推移，插入和更新會擴展索引的中間部分和末尾部分。 為了有效地做到這一點（也就是說，不需要重寫整個表），隨機插入和更新會導致頁面亂序。 創建的新頁面放置在文件中任何有空間的地方。

為了便於瀏覽所有頁面，每個頁面都包含指向下一頁和前一頁位置的鏈接。 這些可能在文件中很遠，所以表掃描實際上不會是連續的，它會涉及到文件中其他位置的許多查找。

InnoDB 要求將頁面加載到 RAM 中，然后才能在查詢中實際使用它們。 InnoDB 緩沖池是固定大小的 RAM 分配，其中包含一組從磁盤加載的頁面。 一旦頁面進入緩沖池，就可以非常快速地訪問它們，並且幾乎沒有跟蹤鏈接的開銷。 將頁面從磁盤讀取到緩沖池的開銷比在 RAM 中讀取頁面要大得多。

所以在 MySQL 的情況下：

• 沒有堆
• 聚集索引的順序與磁盤上的順序存儲無關
• 無論如何都會對 RAM 中的頁面進行讀取，因此磁盤上的物理布局與讀取頁面的順序幾乎沒有關系