一般的に、私のインデックス戦略は次のようになります (私は今のところ SQL Server のみを使用しています - 必要に応じて独自のデータベース システムに適応させます):
- <リ>
良いものを選ぶ クラスタリング キー - GUID や VARCHAR(250) ではありません または何か - 良い クラスタリング キーは、狭く、ユニークで、安定しており、増え続ける - INT IDENTITY のようなもの 完璧です。これをクラスター化された主キーにします -> テーブルの最初のインデックスを提供します
別のテーブルへの外部キーとして使用されている列については、インデックスを追加します。これは、単一の列のインデックスでも、複合インデックスでもかまいません。ケースに最適なものは何でもかまいません。外部キー列が最初であることが重要です そのインデックスの列 (複合インデックスを使用している場合) - それ以外の場合、JOIN の利点 のまたは参照整合性をチェックするためのシステムは利用できません
次に、システムを実行します - 観察し、測定します - ベースラインを確立します。アプリの速度は十分ですか？はいの場合 -> 完了です - 家に帰って余暇を楽しんでください。
そうでない場合:アプリの速度が十分でない理由について、データと兆候の収集を開始します。例を見てください。 SQL Server の DMV のようなもので、パフォーマンスが最も悪いクエリや、行方不明のインデックス DMV について教えてくれます .それらを分析します。改善できる点を確認してください。 一度に 1 つのインデックスを追加します 繰り返しますが、観察し、測定し、ベースラインと比較してください。
改善がある場合 -> その指標をそのままにしておき、この測定値が新しいベースラインになります。あなた (およびあなたのユーザー) がアプリのパフォーマンスに満足するまで (そして その後 家に帰って休暇を楽しみましょう)。
SQL Server での過剰なインデックス作成は悪化する可能性があります インデックスがないよりも。最初からあまりにも多くのインデックスから始めないでください! 良いだけを確立する クラスター化された PK と外部キーの非クラスター化インデックス - それだけです - 次に、そのサイクルを観察、測定、最適化、および繰り返します。