1

少し質問があります。プライマリ インデックスとセカンダリ インデックスのパフォーマンスの違いは何ですか? この違いの原因は何ですか？

私はグーグルで調べており、セカンダリ インデックスが別のテーブルに格納されていることがわかったので、これによりすべての操作が遅くなります..しかし、このパフォーマンスの低下を正当化する他の理由がいくつかありますか?

どうもありがとう

4

1 に答える 1

8

クラスター化されたテーブルは、「ヒープ」部分のないBツリーです。行はクラスター化インデックス（主キー）のBツリー構造に直接格納されます。Bツリーのノードは分割または合体できるため、物理的な場所や行が変更される可能性があります。そのため、セカンダリインデックスから行への単純な「ポインタ」を設定できないため、セカンダリインデックスには次の完全なコピーを含める必要があります。行を確実に識別できるようにするためのプライマリインデックスフィールド。

これは、Oracle、MS SQL Serverに当てはまり、InnoDBにも当てはまります。

つまり、クラスター化テーブルのセカンダリインデックスは、ヒープベースのテーブルのセカンダリインデックスよりも「太い」ということです。

  • データクラスタリングを低下させ、
  • キャッシュの有効性を低下させ、
  • それらを維持するためにより高価になります、
  • そして最も重要なことは、クエリのパフォーマンスに影響を与えることです。
    • セカンダリインデックスを介したクエリには、ダブルルックアップが必要になる場合があります。1つはセカンダリインデックスを介して「キー」データを検索し、もう1つはプライマリを介して行自体を検索します（Oracleには2番目のルックアップを回避するための興味深い最適化がいくつかありますが、InnoDBにはありません。 、 私の知る限り）。
    • 一方、セカンダリインデックスは当然より多くのフィールドをカバーするため、従来のヒープベースのインデックスでテーブルへのアクセスが必要な場合は、2回目のルックアップを完全に回避できます。ただし、ヒープベースのインデックスにフィールドを追加するだけで、同じ効果を得ることができます。

インデックスを使用、ルークを引用させてください！：「インデックス編成テーブルとクラスター化インデックスの利点は、ほとんどの場合、2番目のインデックスを必要としないテーブルに限定されます。」

MySQLではストレージエンジンから独立してクラスタリングを選択できないため、これは残念です。

于 2012-05-23T12:41:39.820 に答える