當我們創建一個聚集索引時，它會占用額外的空間嗎？

Question

我問的是關於 mysql 數據庫的這個問題。我讀到聚集索引根據我們提供的用於制作聚集索引的主鍵或列對表進行排序，而在非聚集索引中，鍵和記錄指針占用了單獨的空間。

另外我讀到沒有單獨的索引表，聚集索引比非聚集索引更快，因為非聚集索引必須首先查看索引表找到相應的記錄指針並獲取記錄數據

這是否意味着聚集索引沒有額外的空間？

PS：我知道這個問題已經有一些類似的答案，但我無法理解。

Answer 1

沒有占用額外空間，因為每個 InnoDB 表都存儲為聚集索引。 實際上只有聚集索引和二級索引。 沒有單獨的數據存儲，因為所有未索引的列都簡單地存儲在聚集索引的終端節點中。 您可能想在此處閱讀更多信息：https://dev.mysql.com/doc/refman/8.0/en/innodb-index-types.ZFC35FDC70D5FC69D269E3Z883A822C75A

確實，如果您使用二級索引進行查找，然后使用二級索引中的 select 列，InnoDB 將執行一種雙重查找。 一次搜索二級索引，這會導致找到您正在搜索的值的主鍵的值，然后它使用這些主鍵來搜索聚集索引以與其他列組合。

自適應 Hash部分緩解了這種雙重查找，它是頻繁搜索值的緩存。 此緩存會在您運行查詢時自動填充。 因此，隨着時間的推移，如果您再次對相同的值運行查詢，成本不會那么高。

Answer 2

情況比你的問題復雜。

首先，我們只討論ENGINE=InnoDB ； 其他引擎的工作方式不同。

• 非葉 BTree 節點將PRIMARY KEY與數據“集群”大約有 1% 的開銷。

• 如果您沒有明確指定PRIMARY KEY ，它可能能夠使用UNIQUE鍵作為 PK。 但如果不是，那么 PK 將使用一個隱藏的 6 字節數字。 這將比如果你有一個 4 字節的INT用於 PK 的空間更多，也就是說，你不能創建沒有PRIMARY KEY的表。

• 以上2項為TMI； 認為 PK 不占用額外空間。

• 是的，通過 PK 查找比通過輔助鍵查找更快。 但是，如果您需要輔助密鑰，請創建它。 玩先獲取 id，然后獲取行的游戲比在單個查詢中完成所有工作要慢。

• 輔助鍵也使用 BTree。 但它按鍵的列排序，不包括所有其他列。 相反，它包括 PK 的列。 （因此比爾提到的“雙重查找”。）

• “覆蓋索引”是包含特定SELECT所需的所有列的索引。 在這種情況下，所有工作都可以在索引的 BTree 中完成，從而避免雙重查找。 也就是說，覆蓋索引與主鍵查找一樣快。 （我猜想 20% 的索引是“覆蓋”的，或者可以通過添加一兩列來覆蓋。）

• BTrees 有很多開銷。 經驗法則：將每列的大小相加（ INT等 4 個字節），然后乘以 2 或 3。結果通常可以很好地估計 Data 或 Index Btree 所需的磁盤空間。

• 本討論不包括FULLEXT或SPATIAL索引。