ある日付タイプのテーブルにフィールドがあり、常に のような比較を使用して検索することがわかっている場合between
、>
またはそれにインデックスを追加しない正当な理由はあり<
ませんか?=
7 に答える
検索するフィールドにインデックスを追加しない唯一の理由は、インデックスを維持するためのコストがその利点よりも重要だからです。
これは、次の場合に発生する可能性があります。
DML
あなたのテーブルには本当にタフな人がいます- インデックスの存在により、インデックスは耐えられないほど遅くなります。
DML
高速なクエリよりも高速であることが重要です。
そうでない場合は、インデックスを作成するだけです。オプティマイザーは、必要がないと判断した場合、それを使用しません。
悪い理由はもっとたくさんあります。
ただし、インデックスが非クラスター化および非カバーの場合、検索列のインデックスでは不十分な場合があります。このようなクエリは、多くの場合、クラスター化インデックスの適切な候補ですが、カバリング インデックスも同様に優れています。
これは、これが科学と同じくらい芸術である理由の良い例です。いくつかの考慮事項:
このテーブルにデータが追加される頻度は? 追加/変更よりも読み取り/検索の方がはるかに多い場合(レポートのためにデータをダンプするいくつかのテーブルの要点)、インデックスに夢中になる必要があります。IDフィールドにはクラスター化インデックスがさらに必要になる場合がありますが、多数の複数列インデックスを作成できます(日付フィールドは後で、インデックスの前にリストされた列は結果セットを減らすのに適しています)。インデックス (すべての戻り値がインデックスにあるため、クラスター化されたインデックスを最初に検索する場合と同様に、非常に高速です)。
テーブルが頻繁に編集/追加される場合、またはストレージ スペースが限られているために大量のインデックスを作成できない場合は、インデックスにもっと注意を払う必要があります。通常、日付基準で広範囲のデータが得られ、他のフィールドを頻繁に検索しない場合は、この日付フィールドにクラスター化インデックスを与えることができますが、それを行う前に何度か考えてください。クラスター化されたインデックスが単純な自動採番フィールドにあることは、すべてのインデックスにとってボーナスです。カバーされていないインデックスは、クラスター化インデックスを使用して、結果セットのレコードを圧縮します。検索の大部分がその日付フィールドにある場合を除き、クラスター化インデックスを日付フィールドに移動しないでください。それが核の選択肢です。
対象となるインデックスを多数作成できない場合 (テーブルのデータが頻繁に変更される、スペースが限られている、結果セットが大きく多様である)、および/または別の列のクラスター化インデックスと通常の日付が本当に必要な場合基準は幅広いレコードを提供し、多くを検索する必要があり、問題があります。レポート テーブルにデータをダンプできる場合は、それを行います。それができない場合は、これらすべての競合する要因のバランスを慎重に取らなければなりません。上位 2 ~ 3 件の検索では、対象となるインデックスを構成できる限り、結果セットの列を最小限に抑え、残りは単純な非クラスター化インデックスに任せます。
優秀なデータベース担当者に高い報酬が支払われるべき理由がわかります。私は多くの要因を知っていますが、多くのプロファイリングを行うことなく、これらすべてのバランスを迅速かつ正確に調整できる人がうらやましいです。
インデックスはテーブルのクエリに役立ちますが、挿入、更新、および削除も多少遅くなります。クエリよりも多くの変更がテーブルにある場合、インデックスによって全体的なパフォーマンスが低下する可能性があります。
毎回テーブル全体をスキャンする場合は、インデックスを作成しないでください。データベースに範囲スキャンを試してもらいたいので、インデックスを追加しますが、SQL Server を使用しており、ほとんどの場合にインデックスが使用されます。ただし、データベースによってはインデックスを使用しないものも多くあります。
BETWEEN
データにもよりますが、テーブル スキャンを避けるために、クエリを実行する場合はクラスター化インデックスを使用することをお勧めします。
テーブルが小さい場合、インデックスを使用しない可能性があるため、インデックスを追加するとリソースが浪費される可能性があります。
インデックスが使用される可能性が低い、または使用できないデータ型 (SQL Server のイメージなど) とデータ分散があります。たとえば、SQL Server では、ビット フィールドにインデックスを付けても意味がありません。インデックスが有効に機能するのに十分な可変性がデータにないためです。
通常、最初の文字として like 句とワイルドカードを使用してクエリを実行する場合、インデックスは使用されないため、インデックスを作成することはリソースの無駄遣いになります。