SELECTで得られたパフォーマンスが、同じテーブルのINSERTのパフォーマンス損失を上回るかどうかを、どのように判断できますか？インデックスが良いよりも害を及ぼしているときに、テーブルのサイズに「転換点」がありますか？SQL Server 2008のインデックス - クエリのパフォーマンス向上とINSERT/UPDATEの損失の比較
SQL Server 2008には、いつでも2〜3百万行のテーブルがあります。表に対して挿入が実行されるたびに、その表の2つの列を使用して同じ表に対してルックアップが実行されます。私は、ルックアップで使用される2つのカラムにインデックスを追加することが有益かどうかを判断しようとしています。
それはに依存SQL関連の他のすべて、同様：
実際に知る唯一の方法は、ベンチマークすることです。インデックスを配置し、頻繁な監視を行うか、トレースを実行します。
+1ベンチマークのために**他のインデックスが役立つか傷つくかを知る唯一の真の**方法。数式で決定する方法はありません - クリスタルボールだけが助けになります（私の店では今...） –
これは、作業負荷と要件によって異なります。時にはデータが一度読み込まれ何百万回も読み込まれることがありますが、読み込まれたすべてのデータが読み込まれることはありません。
読み取りまたは書き込みが一定の時間内に完了する必要がある場合があります。
ケース1：テーブルが静的で、クエリが頻繁に発生する場合（ショッピングカートアプリケーションのアイテムテーブルなど）、適切なフィールドのインデックスは非常に有益です。
ケース2：テーブルが非常に動的で、多くのクエリが日常的に行われない場合（たとえば、監査目的で使用されるログテーブル）、インデックスは書き込みを遅くします。
上記の2つのケースが境界ケースである場合、インデックスを作成するか、またはテーブルにインデックスを作成しないかは、上記のどのような場合に競合するテーブルが最も近いかによって異なります。
Query Tuning Advisorの判断に委ねられない場合。がんばろう。
Kimberly Trippの記事は「[The Tipping Point]（http://www.sqlskills.com/BLOGS/KIMBERLY/category/The-Tipping-Point.aspx）」と呼ばれているので、面白い言葉です。索引の使用を決定する際の決定的な読書と考えられます。 –
@dcp：thx、私は新しいアバターを探していました:) –
うわー。本当に言葉の面白い選択！確かにその記事を読んでいます。それをリンクありがとう。 – TrailJon