3

クラスター化されたインデックスのポイントがわかりません。いつメリットがありますか？

4

4 に答える 4

3

クラスタ化インデックス

クラスタ化されたインデックスとは、インデックスに基づいて、レコードが (少なくとも互いに近くに) 順番に物理的に格納されていることを意味します。クラスタ化インデックスは、各レコードからさまざまな列を順番に取得する場合に最も重要です。これは、データベース エンジンが次のレコードを取得するためにジャンプする必要がないためです。代わりに、レコードは順番に格納されるため、レコード間のシーク時間は最小限に抑えられます。

クラスタ化インデックスは、インデックス内で互いに近くにある複数のレコードを読み取るときに最も重要です。

デフォルトでは、InnoDB では、プライマリ インデックスはクラスター化インデックスです。

クラスタ化インデックスの使用例

Google や Yahoo 検索のようなインクリメンタル検索を行っていた場合、入力を開始すると、それまでに入力した内容と一致する最初のいくつかのレコードが表示されるため、パフォーマンスが最も重要になります。結果セットでインデックス付きの 1 つの列だけを返す場合、クラスター化インデックスは必要ありませんが、データベース エンジンに実際の行へのアクセスを強制して、各 key_word のヒット数も返したいとします。連続した行を返す必要があるため、最適なパフォーマンスを得るには、それらを連続して格納する必要があります。

SELECT key_word, hits FROM keywords
WHERE key_word LIKE 'britney s%'
ORDER BY key_word
LIMIT 10

主キー (クラスター化インデックス) を on にする必要がありますkey_word。

非クラスター化インデックスとの比較

すべてのインデックスは物理的に順番に格納されます (実際には btree ですが、基本的には)。そのため、インデックスに格納されている列だけを返す場合でも、同じ利点が得られます。これは、インデックス化された列の実際の値がインデックスに格納されているためです。したがって、MySQL はレコードを読み取る代わりにインデックス値を使用します。ただし、インデックスの一部ではない列の取得を開始する場合は、クラスター化インデックスの場合など、実際のレコードを順番に格納する必要もあります。

クラスター化インデックスに関する MySQL ドキュメント

行データはインデックス検索が導く同じページにあるため、クラスター化インデックスを介して行にアクセスするのは高速です。テーブルが大きい場合、インデックス レコードとは異なるページを使用して行データを格納するストレージ組織と比較すると、クラスター化インデックス アーキテクチャは多くの場合、ディスク I/O 操作を節約します。(たとえば、MyISAM はデータ行用に 1 つのファイルを使用し、インデックス レコード用に別のファイルを使用します。)

InnoDB では、非クラスター化インデックス (セカンダリ インデックスとも呼ばれます) のレコードには、セカンダリ インデックスにない行の主キー列が含まれています。InnoDB は、この主キー値を使用してクラスター化インデックス内の行を検索します。主キーが長い場合、副次索引はより多くのスペースを使用するため、主キーを短くすると有利です。

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

于 2010-03-23T13:04:03.597 に答える
1

私が考えることができる最も良い例は、トランザクションの日付で定期的にクエリされるレポート テーブルです。クラスター化されたインデックスを TransactionDate 列に配置し、クエリの最適化に基づいて他の必要なインデックスを追加します。

そのため、次のようなクエリselect sum (amount) from transactiondetails where TransactionDate > 'jan 01 2010' and TransactionDate < 'feb 01 2010'はクラスター化インデックスを使用してシークを行い、より効率的な方法で結果を取得します。

于 2010-03-23T13:04:11.537 に答える
1

ファースト ネームで並べられた実際のアドレス帳 (デッド ツリー エディション) は、その構造と目的においてクラスター化インデックスに似ています。

クラスター化インデックスを使用すると、全体的な取得速度が大幅に向上しますが、通常は、データがクラスター化インデックスと同じ順序または逆の順序で順次アクセスされる場合、またはアイテムの範囲が選択されている場合に限られます。

物理レコードはディスク上でこのソート順になっているため、シーケンス内の次の行項目は最後の行項目の直前または直後にあるため、必要なデータ ブロックの読み取りは少なくなります。

出典:ウィキペディア: データベース インデックス - クラスター化

于 2010-03-23T13:05:20.627 に答える
0

ここを見てください 、ページの半分下にあると書かれています：

行データはインデックス検索が導く同じページにあるため、クラスター化インデックスを介して行にアクセスするのは高速です。テーブルが大きい場合、インデックス レコードとは異なるページを使用して行データを格納するストレージ組織と比較すると、クラスター化インデックス アーキテクチャは多くの場合、ディスク I/O 操作を節約します。(たとえば、MyISAM はデータ行用に 1 つのファイルを使用し、インデックス レコード用に別のファイルを使用します。)

速度は私にとって優れた理由のように聞こえます..またはあなたの主張を見逃していますか?

クラスター化インデックスの利点は、「通常の」インデックスよりも少ない io 操作でアクセスできる (したがって検索できる) ことです。これを知っていれば、クラスター化インデックスを最も効果的な場所に配置することで、DB アクセスを最適化し、アプリケーションを最適化できます。

于 2010-03-23T13:02:41.537 に答える