クラスター化されたテーブルは、「ヒープ」部分のないBツリーです。行はクラスター化インデックス（主キー）のBツリー構造に直接格納されます。 Bツリーのノードは分割または合体できるため、物理的な場所や行が変更される可能性があるため、セカンダリインデックスから行への単純な「ポインタ」を設定できないため、セカンダリインデックスには次の完全なコピーを含める必要があります。行を確実に識別できるようにするためのプライマリインデックスフィールド。
これは、Oracle、MS SQL Serverに当てはまり、InnoDBにも当てはまります 。
つまり、クラスター化テーブルのセカンダリインデックスは、ヒープベースのテーブルのセカンダリインデックスよりも「太い」ということです。
- データクラスタリングを低下させます
- キャッシュの有効性を低下させます
- 維持費が高くなります
- そして最も重要なことは、クエリのパフォーマンスに影響を与えることです。
- セカンダリインデックスを介したクエリには、ダブルルックアップが必要になる場合があります。1つはセカンダリインデックスを介して「キー」データを検索し、もう1つはプライマリを介して行自体を検索します（Oracleには、2番目のルックアップを回避するための興味深い最適化がいくつかありますが、私の知る限り、InnoDBはそうではありません。
- 一方、セカンダリインデックスは当然カバー より多くのフィールドがあるため、従来のヒープベースのインデックスでテーブルへのアクセスが必要になる場合は、2回目のルックアップを完全に回避できます。ただし、ヒープベースのインデックスにフィールドを追加するだけで、同じ効果を得ることができます。
インデックスを使用してください、ルーク！ ： "インデックス構成テーブルとクラスター化インデックスの利点は、ほとんどの場合、2番目のインデックスを必要としないテーブルに限定されます。"
MySQLではストレージエンジンから独立してクラスタリングを選択できないため、これは残念です。