MySQL クラスター化インデックスの長所と短所は何ですか

1. クラスタード インデックスとは

データベース インデックスはさまざまな観点からさまざまな種類に分類できますが、クラスタード インデックスもその 1 つです。

クラスタードインデックスは英語でClustered Indexといい、クラスタードインデックスなどと呼んでいる人も時々見かけますが、その反対はノンクラスタードインデックス、セカンダリインデックスです。

クラスター化インデックスは個別のインデックス タイプではなく、データを保存する方法の 1 つです。 MySQL の InnoDB ストレージ エンジンでは、いわゆるクラスター化インデックスは、実際にはインデックスとデータ行を同じ B ツリーに保存します。 この時点で、データはリーフ ノードに配置され、クラスター化され、クラスター化されます。これは、前述のデータ行を意味します。と対応するキー値がコンパクトにまとめて存在します。

次のデータがあるとします:

2ac##男3af88北京女4bc80上海女5bg85重慶bwbwccck cx

id ​​(主キー)	username	age	住所	性別
1	ab	99	深セン	男
	##98	广州
		#女		6
95	天津	男性		7
99	海口	女		8
92	武汉	男性		9
90	深セン	男性		10
93	深セン	男性		そのクラスター化インデックスはおそらく次のようになります: # すると、主キー値 (インデックス) とデータ行の両方がリーフにあることがわかります。 . ノードには主キー値（インデックス）のみが存在します。 考えてみてください、MySQL テーブルのデータはディスク上に 1 つのコピーにのみ保存でき、2 つのコピーを保存することは不可能です。したがって、テーブル内にはクラスター化されたデータは 1 つだけ存在できます。インデックスを 1 つだけ持つことは不可能です。複数。 2. クラスター化インデックスと主キー 友人の中には、この 2 つの関係をよく理解しておらず、この 2 つを同一視している人もいますが、これは大きな誤解です。 一部のデータベースでは、開発者はクラスタ化インデックスとして使用するインデックスを自由に選択できますが、MySQL はこの機能をサポートしていません。 MySQL では、テーブル自体に主キーが設定されている場合、主キーはクラスター化インデックスになります。テーブル自体に主キーが設定されていない場合、テーブル内の一意の空でないインデックスは、 ; テーブル内に一意の空でないインデックスがない場合、テーブル内の暗黙的な主キーがクラスター化インデックスとして自動的に選択されます。 Brother Song は、今後の記事で MySQL テーブルの暗黙的な主キーについて紹介する予定です。 ただし、一般的には、テーブルの主キーを自分で設定することをお勧めします。暗黙の主キーは自動インクリメントされ、自動インクリメントには問題があるためです。非常に高い自動インクリメント値になります。ロック競合の問題では、主キーの上限はホット データと呼ばれます。すべての挿入操作では主キーをインクリメントする必要があり、繰り返すことができないため、ロック競合が発生し、パフォーマンスが低下します。 。 上記の説明に基づいて、MySQL のクラスター化インデックスと主キー インデックスの関係を次のように要約できます。 クラスター化インデックスは必ずしも主キーインデックス。 主キー インデックスはクラスター化インデックスである必要があります。 3. クラスター化インデックスの利点と欠点 最初に利点について話しましょう: 相互に関連するデータを組み合わせることができます。それを一緒に。たとえば、ユーザー注文テーブルがあります。ユーザー ID 注文 ID に基づいてすべてのデータを集計できます。ユーザー ID は繰り返される場合がありますが、注文 ID は繰り返されません。このようにして、すべてのデータを集計できます。ユーザーに関連する注文データをまとめて保存すると、ユーザーのすべての注文をクエリする必要がある場合、非常に高速で、少量のディスク IO のみが必要になります。 テーブルを返す必要がないため、データ アクセスが高速になります。クラスター化インデックスでは、インデックスとデータの両方が同じ B ツリー上にあるため、クラスター化インデックスからのデータの取得は、非クラスター化インデックスからのデータの取得よりも高速です (非クラスター化インデックスにはテーブル バッキングが必要です)。 最初のケースでは、ユーザー ID に基づいてこのユーザーのすべての注文 ID をクエリする場合、現時点ではリーフ ノードに移動する必要はありません。ブランチノードには必要なデータがあるため、カバーインデックスの特性を直接使用して必要なデータを読み取ることができます。 これらはクラスター化インデックスの一般的な利点の一部であり、実際、日常のテーブル設計ではこれらの利点を最大限に活用する必要があります。 欠点を見てみましょう: 私の友人は、前に述べたクラスター化インデックスの利点は主に、クラスター化インデックスによって IO の数が削減されることであることに気付きました。これにより、データベースのパフォーマンスが向上しますが、一部の IO 集約型アプリケーションでは、操作のためにすべてのデータをメモリに読み込むのに十分な大きさのメモリを直接ロードする場合があります。この場合、クラスター化インデックスには利点がありません。 ランダムな主キーはページ分割の問題を引き起こします。主キーを順番に挿入すると、B ツリーでは最後に追加し続けるだけで済むため、比較的効率的になります。 ; ただし、主キーが非順次挿入の場合、ページ分割が含まれる可能性があるため、効率は大幅に低下します。上の図を例として、各ノードが 3 つのデータを保存できると仮定し、主キー 4.5 を持つレコードを挿入したい場合は、主キー 5 の値を戻す必要があります。これにより、主キーが 8 のノードも元に戻ります。ページを分割すると、データ挿入の効率が低下し、より多くの記憶域スペースが必要になります。 非クラスター化インデックス (セカンダリ インデックス) をクエリする場合は、テーブルを返す必要があります。インデックスはインデックス ツリーであり、データはすべてクラスター化インデックス上にあるため、非クラスター化インデックスを使用して検索する場合、非クラスター化インデックスのリーフには主キー値が格納されます。最初に主キー値を検索します。次に、主キー値がクラスタード・インデックスで検索され、合計 2 つのインデックス・ツリーが照会され、これがテーブルの戻り値となります。

以上がMySQL クラスター化インデックスの長所と短所は何ですかの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。