インデックスが必要か必要かを判断する方法
MS SQLデータベースで自動インデックスツールを実行しています（Microsoftのインデックス統計テーブルを参照するスクリプトを変更しました 自動化された自動インデックス ）。統計から、作成が必要なインデックスの推奨事項のリストを取得しました。
編集：上記のインデックスは、DMVから、データベースエンジンがインデックスに何を使用するかを示す情報を取得します利用可能であり、スクリプトは（シーク、ユーザーへの影響などによる）上位xの推奨事項を取り、それらを表に入れます。
（上記の編集は、スクリプトが何をしているかを明確にするために、以下のLarry Colemanの回答から一部抜粋したものです）
私はデータベース管理者の初心者であり、ネット全体をすばやく検索していたので、思い切って推奨インデックスを盲目的に追加したくありません。ただし、現場での経験がないため、推奨が必要かどうかを判断する方法についてのアドバイスを探しています。
SQLプロファイラーを実行する必要がありますか、それともテーブルをクエリするコードを調べる方が良いですか？そして、他に何かアドバイスはありますか？
私は Jason Strateのインデックス分析スクリプト（古い場所） を使用します。これらは、既存のインデックスが使用されている量と、失われたインデックスが使用されていたであろう量を示します。テーブルに対するクエリの5％または10％以上を構成しない限り、通常はインデックスを追加しません。
ただし、最も重要なのは、アプリケーションがユーザーに対して十分に速く応答するようにすることです。
更新：Jason Strateの新しいスクリプト用のインデックス分析ブログ記事（新しい場所）
二重更新：最近では、インデックス分析を実行するときに sp_BlitzIndex® を使用しています。
インデックスを扱うときに理解しておくべき重要な概念と用語がいくつかあります。シーク、スキャン、ルックアップは、selectステートメントを通じてインデックスを利用する方法の一部です。キー列の選択性は、インデックスがどれほど効果的であるかを決定するために不可欠です。
シークは、SQL Serverクエリオプティマイザーが、要求したデータを検索する最良の方法がインデックス内の範囲をスキャンすることであると判断したときに発生します。シークは通常、クエリがインデックスによって "カバー"されている場合に発生します。つまり、シーク述語がインデックスキーにあり、表示された列がキーに含まれているか含まれています。スキャンは、SQL Serverクエリオプティマイザーがデータ全体を検索する最良の方法がインデックス全体をスキャンしてから結果をフィルター処理することであると判断したときに行われます。通常、ルックアップは、インデックスキーまたは含まれている列のいずれかに、要求されたすべての列がインデックスに含まれていない場合に発生します。クエリオプティマイザーは、クラスター化キー（クラスター化インデックスに対して）またはRID（ヒープに対して）のいずれかを使用して、他の要求された列を「検索」します。
一般的に、シーク操作は、より小さいデータセットを物理的にクエリするため、スキャンよりも効率的です。非常に小さい初期データセットなど、これが当てはまらない状況もありますが、それは質問の範囲を超えています。
ここで、インデックスの効果を判断する方法を尋ねましたが、留意すべき点がいくつかあります。クラスタ化インデックスのキー列は、クラスタリングキーと呼ばれます。これは、クラスター化インデックスのコンテキストでレコードを一意にする方法です。すべての非クラスター化インデックスには、必要に応じてルックアップを実行するために、デフォルトでクラスター化キーが含まれます。すべてのインデックスは、それぞれのDMLステートメントに対して挿入、更新、または削除されます。そうは言っても、selectステートメントでのパフォーマンスの向上と、insert、delete、およびupdateステートメントでのパフォーマンスのヒットとのバランスをとることが最善です。
インデックスの有効性を判断するには、インデックスキーの選択性を判断する必要があります。選択性は、合計レコードに対する個別のレコードの割合として定義できます。合計100レコードの[person]テーブルがあり、[first_name]列に90個の異なる値が含まれている場合、[first_name]列は90％選択的であると言えます。選択性が高いほど、インデックスキーの効率が高くなります。選択性を念頭に置いて、最も選択的な列をインデックスキーの最初に置くことをお勧めします。前の[person]の例を使用して、95％の選択率の[last_name]列がある場合はどうなりますか？ [last_name]、[first_name]をインデックスキーとしてインデックスを作成します。
これは少し時間のかかる答えだったと思いますが、インデックスがどれほど効果的であるかを決定するために多くの事柄があり、パフォーマンスの向上を比較検討しなければならない多くの事柄があります。
私は最近、BrentOzar Unltdの人々から素晴らしい無料のスクリプトを発見しました http://www.brentozar.com/blitzindex/
これは、存在するインデックス、それらが使用される頻度、およびクエリエンジンが存在しないインデックスを探す頻度について、いくつかの優れた分析を行います。
ガイダンスは概ね良好です。時にはそれはアイデアを少し示唆しすぎることがあります。私はこれまで一般的に次のことを行ってきました。
- 一度も読み込まれたことがない（または月に50回未満）インデックスが削除されました。
- 私たちがよく使用する外部キーとフィールドに最も明白なインデックスを追加しました。
すべての推奨インデックスを追加していませんが、クエリエンジンが代わりに他の新しいインデックスの一部を使用しているため、推奨されなくなったことが1週間後にわかりました。
一般に、次のインデックスは使用しないでください。
- 非常に小さなテーブル（50〜200レコード未満）：多くの場合、クエリエンジンは、インデックスの読み込み、読み取り、処理などを行うよりも、テーブルをスキャンする方が高速です。
- カーディナリティの低い列のインデックスは避けてください（ http://en.wikipedia.org/wiki/Cardinality_(SQL_statements） ）最初に言及した列。たとえば、性別フィールド（M/F）のインデックス作成はほとんど役に立ちません、テーブルをスキャンして一致する〜50％を見つけるのも同じように実用的です。それがインデックスでより具体的なもの（[生年月日、性別]など）の後にリストされている場合、それはより良いです。期間。
クラスタ化インデックスは適切です。通常、これらは主キーに基づいています。これらは、データベースエンジンがデータをディスクに適切な順序で配置するのに役立ちます。優れたクラスター化インデックスは多くの場合、テーブルが占有するスペースを減らすため、最大のテーブルについてこれを理解することは非常に重要です。
テーブルが事前に構造化されていないヒープであったため、一部のテーブルを900MBから400MBに減らしました。 http://msdn.Microsoft.com/en-us/library/aa933131(v=sql.80).aspx
再編成/再構築
断片化されたインデックスをチェックする必要があります。少しの断片化は大丈夫です、執着しないでください！ http://technet.Microsoft.com/en-us/library/ms189858.aspx 再編成と再構築の違いを知ってください！
定期的に見直す
クエリの変更、データ量の変更、新機能の追加、古い機能の削除。 1か月に1回（またはボリュームが大きい場合はさらに頻繁に）それらを調べ、データベースを支援できる場所を探す必要があります。
幾つ
最近のビデオでは、ブレントは（通常）書き込みの多いテーブル（注文テーブルなど）に5つ以上のインデックスを推奨していません。書き込みよりも多く読み取られている場合（つまり、分析用のログテーブル） http ：//www.youtube.com/watch？v = gOsflkQkHjg
全体
場合によります！
あなたの走行距離はデータベースによって異なります。より大きな（現在/将来の）テーブルで明白な（従業員の姓、注文日など）をカバーします。必要に応じて監視、確認、調整します。データベースを管理する場合、これは定期的なチェックリストの一部である必要があります:)
お役に立てれば！
通常、特定のワークロード（クエリ）を用意し、新しいインデックスごとのワークロードへの影響を慎重にテストします。この反復プロセスには、実行プランの慎重な分析が常に含まれている必要があります。これにより、使用されているインデックスが明らかになります。クエリの分析というトピックは非常に長く、MSDNの専用の章 クエリの分析 から始めるのがよいでしょう。
ワークロードが複雑すぎる場合、またはデータベース設計の知識が不完全な場合、 データベースエンジンチューニングアドバイザー を使用します。これは、ワークロードの自動分析をいくつか実行し、いくつかのインデックスを提案します。もちろん、提案は慎重に分析し、影響をすぐに測定する必要があります。
したがって、私のアイデアに従うと、インデックスを追加して影響を測定することは、実際には A/Bテスト の場合にすぎません。インデックスなしでワークロードを実行し、ベースラインとして実行します。インデックスを使用して、測定してベースラインと比較し、観測および測定されたメトリックに基づいて、影響が有益かどうかを判断します。ワークロードは最高の高品質のテストスイートですが、キャプチャされたワークロードの再生でもかまいません。 方法：トレースファイルの再生 を参照してください。
より総合的な答えは sys.dm_db_index_usage_stats インデックスがどのように使用されているかを表示して確認しますが、これは通常、未知のワークロードでオンサイト分析を行うためのアプローチです（つまり、コンサルタントに連絡して、おそらくこれから始めます）。
SQL 2005以降、SQL Serverには [〜＃〜] dmv [〜＃〜] があります。これは、データベースエンジンが使用可能な場合にデータベースエンジンがインデックスに何を使用するかを示します。ビューは、どの列をキー列にする必要があるか、どの列を含める必要があるか、そして最も重要なことには、インデックスが使用された回数を知ることができます。
良い方法は、不足しているインデックスクエリをシーク数で並べ替え、最初に上位のインデックスを追加することを検討することです。
参照： 公式のMS DMVドキュメント