2

テーブルにインデックスを追加したいと考えています。テーブルにインデックスを追加する方法の一般的なアイデアを探しています。クラスター化された PK 以外。これを行うときに何を探すべきかを知りたいです。だから、私の例：

このテーブル (TASK テーブルと呼びましょう) は、アプリケーション全体で最大のテーブルになります。数百万のレコードを期待しています。

重要: 大量の一括挿入により、このテーブルにデータが追加されます

テーブルには 27 列あります: (これまでのところ、カウント :D )

int x 9 列 = id-s

varchar x 10 列

ビット×2列

日時×5列

整数列

これらはすべて INT ID ですが、通常はタスク テーブル (最大 10 ～ 50 レコード) よりも小さいテーブルからのものです。例: ステータス テーブル (「オープン」、「クローズ」などの値) または優先度テーブル (「」などの値)重要」「あまり重要ではない」「普通」）「親ID」（自己ID）みたいな欄もあります

結合：すべての「小さな」テーブルにはPKがあり、通常の方法で...クラスター化されています

文字列列

「常に5文字の長さ」のような（会社）列（文字列！）があり、すべてのユーザーはこれを使用して制限されます。タスクに 15 の異なる「会社」がある場合、ログインしたユーザーには 1 つしか表示されません。したがって、これには常にフィルターがあります。この列にインデックスを追加することをお勧めしますか?

日付列

彼らはこれらを索引付けしていないと思います...そうですか？それともできる/すべきですか？

4

3 に答える 3

5

パフォーマンスの問題など、特定の理由がない限り、インデックスを追加しません。

追加するインデックスの種類を把握するには、次のことを知る必要があります。

  • テーブルに対して使用されているクエリの種類 -WHERE句とは何か、何をしているのORDER BYか

  • あなたのデータはどのように配布されていますか？インデックス作成に役立つほど十分に選択的 (データの 2% 未満) な列はどれか

  • 追加のインデックスがテーブルの INSERT と UPDATE にどのような (マイナスの) 影響を与えるか

  • 他のテーブルへの JOIN を高速化するために、すべての外部キー列をインデックスの一部にする必要があります (できればインデックスの最初の列として)。

そして、確かに列にインデックスを付けることができDATETIMEます-できないと思った理由は何ですか?? 日付範囲によって結果セットを制限する多くのクエリがある場合、DATETIME列にインデックスを付けるのは完全に理にかなっています。おそらくそれ自体ではなく、テーブルの他の要素と一緒に複合インデックスを作成します。

インデックスを作成できないのは、900 バイトを超えるデータを保持する列ですVARCHAR(1000)。

インデックス作成に関する非常に詳細で知識豊富な背景については、インデックス作成の女王であるKimberly Tripp によるブログを参照してください。

于 2010-12-22T15:51:21.187 に答える
3

一般に、インデックスは JOIN、並べ替え操作、およびフィルターを高速化します

SO 列が JOIN、ORDER BY、または WHERE 句にある場合、インデックスはパフォーマンスの面で役立ちます...しかし、常にあります...ただし、UPDATE、DELETE、および INSERT 操作を追加するすべてのインデックスでインデックスを維持する必要があるため、速度が低下する

答えは...それは依存します

クエリでテーブルをヒットし始め、スキャンの実行計画を見て、SARGableクエリを作成するか、必要に応じてインデックスを追加して、それらのシークを試みてください...インデックスを追加するためだけにインデックスを追加しないでください

于 2010-12-22T15:50:36.750 に答える
1

ステップ 1 は、テーブル内のデータがどのように使用されるか、つまりどのように挿入、選択、更新、削除されるかを理解することです。使用パターンを知らずに、暗闇で撮影しています。(また、今思いついたことが何であれ、間違っている可能性があることに注意してください。起動して実行したら、決定を実際の使用パターンと比較してください。) いくつかのアイデア:

ユーザーがテーブル内の個々のアイテムを頻繁に検索する場合、主キーのインデックスは重要です。

データが非常に頻繁に挿入され、複数のインデックスがある場合、時間の経過とともにインデックスの断片化に対処する必要があります。クラスター化インデックスと非クラスター化インデックス、および断片化 (ALTER INDEX...REBUILD) を読んで理解してください。

ただし、大量の行を取得する必要がある状況でパフォーマンスが重要な場合は、それをサポートするためにクラスター化インデックスを使用することを検討してください。

ステータスに基づく一連のデータが頻繁に必要な場合は、その列のインデックス作成が適しています。特に、行の 1% が「アクティブ」であるのに対し、99% が「アクティブでない」であり、必要なのはアクティブな行のみである場合です。

逆に、「PriorityId」が PriorityId 42 が何であるかを示す「ラベル」を取得するためだけに使用される場合 (つまり、ルックアップ テーブルに結合する場合)、おそらくメイン テーブルにインデックスは必要ありません。

最後のアイデアとして、誰もが常に一度に 1 つの会社のデータのみを取得する場合、(a) 間違いなくそのデータにインデックスを付ける必要があり、(b) その値でテーブルを分割することを検討する必要があるかもしれません。従来のインデックス作成を超えた「組み込みフィルター」として機能します。(これはおそらく少し極端であり、エンタープライズ版でのみ利用可能ですが、あなたのケースでは価値があるかもしれません.)

于 2010-12-22T15:59:38.003 に答える