Zenn
✨

クラスタインデックスとセカンダリインデックス

に公開
パフォーマンス
tech

そのZenn記事（MySQL/InnoDBでまず押さえておきたいSQLパフォーマンスチューニングの基礎）の**「クラスタインデックスとセカンダリインデックス」**の部分の要点は、ざっくり言うとこうです：

✅ 結論：InnoDBでは主キー（クラスタインデックス）に依存する構造なので、セカンダリインデックスを使うときにも「主キーアクセスが必ず発生する」＝効率に差が出る。

🧠 キーワードの意味から整理

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

  • InnoDBのテーブルそのものの構造＝データそのものが主キー順に格納されている
  • 主キーアクセス（WHERE id = 1など）は、インデックス1回アクセスだけで済む（効率◎）

🟠 セカンダリインデックス（補助インデックス）

  • 主キー以外のカラムにインデックスを貼ったもの（例：name, email など）
  • 実際のデータにアクセスするには、セカンダリインデックス → 主キー → データ本体という2段階アクセスになる（＝オーバーヘッド）

💥 この記事で言いたいこと（要約）

  1. 主キーアクセス（クラスタインデックス）は1回でデータを取れる

    • → 最も高速

  2. セカンダリインデックスを使うと、結局主キーも必要になる

    • → 「カバリングインデックス（後述）」でない限り、二度読みが発生するので遅くなる

  3. セカンダリインデックスの選び方や使い方を間違えると逆効果

🧪 具体例（記事から）

SELECT * FROM users WHERE name = 'John';

  • name にセカンダリインデックスがある場合：

    1. name = 'John' で該当レコードの主キーを探す（1回目のアクセス）
    2. その主キーを使って、クラスタインデックスから実データを取る（2回目）

→ 合計 2段階アクセス。これが非効率なケースもある。

💡 じゃあ何を意識すればいいの？

  • できるだけ主キーでアクセスできる設計にする
  • セカンダリインデックスを使うときは、「そのインデックスだけで完結するクエリ」（カバリングインデックス）を目指す
  • セカンダリインデックスを多用する場合は、実行計画（EXPLAIN）でアクセス回数を確認

📝 一言まとめ

InnoDBでは「データは主キー順に格納」されており、セカンダリインデックスを使っても最終的には主キーにアクセスが必要。
だから、「セカンダリインデックス＝即高速化」ではないという点に注意しよう。

もし、「どう設計すればいいの？」とか「カバリングインデックスの具体例もほしい」などあれば、続けて説明できます！どうしましょう？

Discussion