sql - SQL Server クラスター化インデックス - インデックスの順序に関する質問

Question

私は次のようなテーブルを持っています:

keyA keyB data

keyA と keyB は一緒に一意であり、テーブルの主キーであり、クラスター化インデックスを構成しています。

keyB の可能な値は 5 つですが、keyA の可能な値の数は無制限です。通常、keyB は増加します。

たとえば、次のデータは、どちらのキー列が最初に並べられるかに応じて、2 つの方法で並べ替えることができます。

keyA keyB data
A    1    X
B    1    X
A    3    X
B    3    X
A    5    X
B    5    X
A    7    X
B    7    X

また

keyA keyB data
A    1    X
A    3    X
A    5    X
A    7    X
B    1    X
B    3    X
B    5    X
B    7    X

最初にその値でデータを並べ替えることができるように、どのキー列の値が少ないかをクラスター化インデックスに伝える必要がありますか? それとも、どちらを先に注文するか性能的に関係ないですか？

Answer 1

最も選択的な列を持つ複合クラスター化インデックスを最初に注文する必要があります。これは、合計行数と比較して最も明確な値を持つ列を意味します。

「B*TREEインデックスは、テーブルからわずかな割合の行を選択するクエリのパフォーマンスを向上させます。」 http://www.akadia.com/services/ora_index_selectivity.html？

この記事はOracleを対象としていますが、それでも関連性があります。

また、常に実行され、いくつかのフィールドを返すクエリがある場合は、すべてのフィールドを含む複合インデックスを作成することを検討してください。ベーステーブルにアクセスする必要はありませんが、代わりにインデックスからデータを取得します。

複合インデックスの最初の列に必ず言及することに関するligget78のコメントは、覚えておくことが重要です。

Answer 2

（keyA、keyB）を使用して（クラスター化されているかどうかに関係なく）インデックスを作成する場合、これが値の順序付け方法です。たとえば、最初のkeyA、次にkeyBです（これは質問の2番目のケースです）。逆にしたい場合は、(keyB, keyA) を指定する必要があります。

もちろん、クエリによっては、パフォーマンスが重要になる可能性があります。たとえば、(keyA, keyB) インデックスがあり、クエリが WHERE keyB = ... (keyA に言及せずに) のように見える場合、インデックスは利用できません。

Answer 3

他の人が言っているように、順序は、インデックス作成スクリプト（またはPK制約）で指定する方法に基づいています。ただし、クラスター化インデックスについての1つのことは、覚えておくべきことがたくさんあるということです。

PK以外でクラスター化インデックスを使用すると、全体的なパフォーマンスが向上する場合があります。たとえば、金融システムを作成していて、レポートがほとんどの場合、アクティビティの日時（過去1年間のすべてのアクティビティなど）に基づいている場合は、その日付列のクラスター化インデックスの方が適している可能性があります。HLGEMが言うように、ソートはクラスター化されたインデックスの選択によっても影響を受ける可能性があります。

クラスタ化インデックスは、他のインデックスよりも挿入に影響を与える可能性があります。大量の挿入があり、クラスター化インデックスがIDENTITY列のようなものにある場合、すべての新しい行が同じ場所に挿入されるため、ディスクのその特定の部分で競合の問題が発生する可能性があります。

小さなルックアップテーブルの場合、私は常にクラスター化インデックスをPKに配置します。影響の大きいテーブルの場合は、最適なインデックスを選択する前に、考えられるさまざまなクラスター化インデックスについて検討（およびテスト）することをお勧めします。

Answer 4

クラスター化インデックスは、テーブルがディスクに格納される物理的な順序であることに注意してください。

したがって、クラスター化インデックスが ColA として定義されている場合、ColB クエリは、クラスター化インデックスと同じ順序で並べると高速になります。SQL が B、A を順序付けする必要がある場合、正しい順序を達成するために実行後の並べ替えが必要になります。

私の提案は、B、A に 2 つ目の非クラスター化インデックスを追加することです。また、データ列のサイズに応じて、INCLUDE (含まれる列を読み取る) することで、キーの検索が不要になります。もちろん、クエリ速度と書き込み速度のバランスを取る必要があるため、このテーブルが大量に挿入されていないことが前提です。

現実的には、クラスター化インデックスは、データがアクセスされる可能性が最も高い順序を表し、挿入/更新 IO コストの微妙なバランスを維持する必要があります。クラスター化インデックスが常にページの途中に挿入されるようなものである場合、そこでパフォーマンスが低下する可能性があります。

他の人が言ったように、テーブルの長さ、列のサイズなどを知らなければ正解はありません。大量のテストを伴う試行錯誤が最善の策です。

Answer 5

SQL Server は、あなたが言ったとおりに注文していると思います。インデックスへのアクセス方法をよく知っていることを前提としています。

いずれにせよ、データベースがそれを理解してくれることを期待するのではなく、可能な場合は、必要なものを正確に指定することをお勧めします。

また、両方の方法を試して、代表的なクエリを多数実行し、生成された実行計画を比較して、どちらが最適かを判断することもできます。

Answer 6

これが明らかでない場合に備えて:インデックスの並べ替え順序は、クエリの結果の並べ替え順序についてあまり約束しません。

クエリでは、引き続き追加する必要があります

ORDER BY KeyA, KeyB

また

ORDER BY KeyB, KeyA

オプティマイザーは、インデックス内で既に物理的に順序付けされたデータを見つけて、時間を節約できることを喜んでいるかもしれませんが、特定の順序でデータを配信することになっているすべてのクエリには、最後に ORDER BY 句が必要です。order by がないと、SQL Server はレコードセットの順序に関して何の保証もせず、クエリごとに同じ順序で返されることさえ約束しません。

Answer 7

最善の方法は、両方のソリューションを試して実行時間を測定することです。

私の経験では、インデックスの調整は正確な科学に他なりません。

おそらく、インデックス列の順序でkeyAの前にkeyBを配置する方が良いでしょう

Answer 8

レポートやクエリで通常ソートする順序で列を指定します。

ただし、複数列のクラスター化インデックスを作成することには注意が必要です。この幅によっては、作成する他のインデックスのサイズに大きな影響を与える可能性があります。これは、すべての非クラスター化インデックスにクラスター化インデックス値が含まれているためです。また、値が頻繁に変更される場合は、行を並べ替える必要があります。私の経験では、非代理キーはより頻繁に変更される傾向があります。したがって、これをクラスター化された副非クラスター化インデックスとして作成すると、変更される可能性のある値がある場合、サーバー リソースの消費時間が大幅に長くなる可能性があります。列に実際に含まれるデータの種類がわからないため、これを行うべきではないと言っているわけではありません (ただし、A1、a2 などよりも複雑であると思われます)。それを行うことの影響について考える必要があると言っているのです。

Answer 9

はい、提案する必要があります。通常、クエリ エンジンは最適な実行プランと使用するインデックスを見つけようとしますが、クエリ エンジンに特定のインデックスを強制的に使用させる方がよい場合もあります。インデックスを計画するとき、およびクエリでインデックスを利用するときは、他にもいくつかの考慮事項があります。たとえば、index での列の順序、where 句での列の順序などです。次のリンクを参照して、次のことを知ることができます。

http://ashishkhandelwal.arkutil.com/sql-server/quick-and-short-database-indexes/

• インデックスを使用するためのベスト プラクティス
• 最高のパフォーマンス フォーム インデックスを取得する方法
• クラスタ化インデックスに関する考慮事項
• 非クラスター化インデックスに関する考慮事項

これは、インデックスを計画するときに役立つと確信しています。