BTree木

いい質問です！ここが クラスタ化インデックス (Clustered Index) と 副次索引 (Secondary Index) の大きな違いどころですね。

InnoDB を例に解説しますね。

⸻

1. クラスタ化インデックス (Clustered Index)

• テーブルデータ自体が B+Tree の葉ノードに格納される

• つまり「主キーインデックスの B+Tree = テーブルそのもの」

• 葉ノードには「主キー値 + その他のカラム全体」が保存される

👉 なので 主キー検索が最速（B+Treeをたどって葉に到達したら、すでに行データがそこにある）。

⸻

2. 副次索引 (Secondary Index)

• 副次インデックスも B+Tree で管理される

• ただし、葉ノードに格納されるのは 検索対象カラムの値 + 主キー値

• 実際の行データは入っていない

• 実際のレコードを取りに行くときは、さらに主キーのクラスタ化インデックスをたどる必要がある

👉 この動きを「インデックスルックアップ（二度引き）」と呼びます。

⸻

3. イメージ図

クラスタ化インデックス（主キー id）

B+Tree (id)

• 葉ノードにレコード全体が保存されている

⸻

副次インデックス（name列のインデックス）

B+Tree (name)

• 葉ノードには「name + 主キー」しかない

• 実際の行を取るときは、さらに「id=10」をクラスタ化インデックスで探す必要がある

⸻

4. 性能上の違い

• 主キー検索（クラスタ化インデックス）

• B+Treeを1回たどるだけで行データ取得完了 → 高速

• 副次索引検索

• B+Treeをたどって主キーを見つけ → さらにクラスタ化インデックスで行データを探す

• インデックスルックアップが発生 → コスト増

⸻

✅ まとめ

• 両方とも B+Tree 構造を使うが、葉ノードに格納される内容が違う

• クラスタ化インデックス → 葉にレコード本体がある

• 副次索引 → 葉には「索引カラム + 主キー」だけ。実データ参照は主キーのB+Treeを再探索する必要あり

⸻

💡ここで質問ですが、今気になっているのは

• 「副次インデックスが2回探索になる仕組み」なのか

• それとも「クラスタ化と副次でB+Tree構造そのものが違うのか」

どっちを深掘りしたいですか？