一つは、多くの場合、インデックスが更新クエリのパフォーマンスにマイナスの影響を持っていることを読み取ります。 私は、もう少し正確なの影響を判断するために私たちの内部テーブルのいずれかのマイクロベンチマークを実現しました。

表では、550メガバイトの重さ8列を有するライン8555648の生産のために使用されるテーブルです。 これらの列の1つは、単一の電子メールフィールドであり、別のdatetime形式でデータベースへの統合の日付です。

私が使用するアプリケーションは、次のとおりです。

 更新R_Temp.dbo.Email
 Date_In = '04 / 09/2008 'を設定する
どこでメールアドレス（ 'test@gmail.com'）
 nullとDate_Inです。 

ここでインデックスなしテーブルの上に推定実行プランは、次のとおりです。

インデックスが存在しないため、SQL Serverは完全にクエリに一致する行を見つけるためにテーブルをスキャンすると言うことですテーブル·スキャンを実行する必要があります。 ここでは、このスキャンのコストは、次のとおりです。

推定I / Oコスト：52.1454
推定CPUコスト：4.70565
推定演算コスト：56.8511
推定サブツリーコスト：56.8511

"更新のインデックスタイプの影響"を読み続ける

SQLクエリのパフォーマンスを向上させるためには、最も頻繁に与えられた "インデックスを作成する"です。 これは残念ながらそれほど単純ではありませんが、インデックスは変わる場合が長所と短所を含むインデックスの2つの主要なタイプがあることは言うに及ばず、特定の種​​類の問合せを最適化されません。 だから常に彼らがもたらす可能性があり問題と比較して、インデックスの利益を完全に反射を作るだけでなく、インデックスが実際にクエリのパフォーマンスにプラスの影響を持っていることを確認するために一連のテストを実行します。使用されます。 でも、単純なSELECTクエリは、インデックスの恩恵を受けることはできません。

これを説明するために私は、インデックス（ヒープ）、順序付けされたインデックス（クラスタ化）し、次の問合せで順序付けインデックス（非クラスタ）を使用せずにテーブルのパフォーマンスを比較するのSQLServer 2005のマイクロベンチマークを行った：

 希望R_Temp.dbo.EMAILメールからcount（*）を選択します（ 'フレッド％'） 

テーブルには、8555648行が含まれている550 MBの重量を量り、8つのカラムで構成されています。 [電子メール]フィールドはユニークです。

ここでインデックスなしテーブルの上にこのクエリの推定実行プランは、次のとおりです。

SQLServerのクエリに一致する行を見つけるためにここで全体の表（表スキャン）を横断しなければならず、コストが非常に高いです：それは私のサーバ上で2.5秒で実行されます。

"選択のインデックスのタイプの影響"を読み続ける