質問はそれをすべて言います。私はこれまで、最適化のために WHERE ステートメントで使用した列のインデックスを配置し、サイトが適切にスケーリングされるようにしました。私は、これらのインデックスを配置せず、必要に応じて最適化のために場所を残すことが最善であると言う同僚と話しています。ここでのベストプラクティスは何だと思いますか?
4 に答える
答えは、いつものように、「場合による」です。
WHERE 句がインデックス作成が壊れるような方法で列を使用している場合、わざわざする必要はありません。可能であれば、それらを書き換えたいと思うでしょう。
INSERT の際にインデックスを計算する必要があるため、クエリと比べてコストがかかります。ほとんどの場合、索引付けは理にかなっているかもしれません。データベースのトランザクションが多い場合、インデックスによって INSERT が遅くなります。特に一括アップロード。
ここでのベスト プラクティスは、最初にいくつかのインデックスを配置することだと思います。どのインデックスが必要になるかを推測するためです。しかしその後、どのクエリが遅いかを実際に測定し、それらをインデックス化する必要があります。要件が変わると、where 句やクエリ全体が変わる可能性があります。
これは、 pgfouineのように、1 日のクエリ時間を集計するものを使用するのと同じくらい簡単です。
私はノーと言わなければならないでしょう:それはたまたまWHERE
節に現れるので、単にすべての列にインデックスを付けるのは良い習慣ではありません。
まず、特定のWHERE
句に2つの列がある場合、同じインデックスの両方にインデックスを付けるかどうか、およびどちらを最初の列にするかを決定する必要がある場合があります。単一の列だけで、インデックス内ASCENDING
またはDESCENDING
インデックス内の選択が重要になる可能性があります。同じテーブルが多くのクエリに参加し、句に多くの列があるWHERE
場合、列が句に表示されるという理由だけで、これらすべての列をさまざまな組み合わせと順序で持つ多数のインデックスが必要WHERE
ですか?いいえ。
句で使用される列を考慮してインデックスを設計することをお勧めしますが、最終的には、句に表示されないが、に表示される列は、ほとんどのインデックスにとってより重要になる可能性があります。検査を使用していくつかのインデックスを設計することは確かにできますが、一般に、プロセスを実際にプロファイリングして、ワークロードの大部分に実際に役立つインデックスを確認する必要があります。WHERE
WHERE
JOIN
いいえ。カラムの選択性によって異なります。たとえば、列EMPLOYEE.GENDERにインデックスを付けることは意味がありません。おそらくCOLLEGE_STUDENT.YEAR_IN_SCHOOL_STATUS(4つの可能性のある値)でもありません。
1つまたは2つの一般的な値が散在するまれな値がいくつかある場合は、部分インデックスを作成できます。
行の10%を超える値がないクエリで使用されるフィールドには、間違いなくインデックスを付けます。