ショートバージョン：シークははるかに優れています
短いバージョン：シークは一般的にはるかに優れていますが、シークは非常に多くあります（たとえば、厄介な相関サブクエリを使用した不適切なクエリデザイン、またはカーソル操作や他のループで多くのクエリを作成しているため）。特に、クエリが影響を受けるテーブルのほとんどの行からデータを返す可能性がある場合にスキャンします。
データ検索操作のファミリ全体をカバーして、パフォーマンスへの影響を完全に理解するのに役立ちます。
テーブルスキャン：クエリに関連するインデックスがまったくない場合、プランナーはテーブルスキャンの使用を強制されます。つまり、すべての行が参照されます。これにより、テーブルのデータに関連するすべてのページがディスクから読み取られる可能性があり、これは多くの場合最悪の場合です。いくつかのクエリでは、有用なインデックスが存在する場合でもテーブルスキャンを使用することに注意してください-これは通常、テーブル内のデータが非常に小さいため、インデックスを走査するのが面倒であるためです（この場合は、インデックスの選択性の指標が適切であると仮定して、データが大きくなるにつれて変更する計画を立ててください）。
行ルックアップを使用したインデックススキャン：シークに直接使用できるインデックスは見つかりませんが、適切な列を含むインデックスが存在する場合、インデックススキャンを使用できます。たとえば、column1、col2、col3にインデックスを持つ20列の大きなテーブルがあり、を発行するSELECT col4 FROM exampletable WHERE col2=616場合、この場合、インデックスをスキャンしてクエリするcol2方が、テーブル全体をスキャンするよりも優れています。一致する行が見つかったら、出力（またはさらに結合）のためにデータページをピックアップcol4に読み込む必要があります。これは、クエリプランで表示されるときの "ブックマークルックアップ"ステージです。
行ルックアップを使用しないインデックススキャン：上記の例の場合、SELECT col1, col2, col3 FROM exampletable WHERE col2=616データページの読み取りに余分な労力は必要ありません。インデックス行の一致col2=616が見つかると、要求されたすべてのデータがわかります。このため、検索されない列が表示されることがありますが、出力の要求があり、インデックスの最後に追加される可能性があります。行の検索を保存できます。この理由およびこの理由のみで列をインデックスに追加するINCLUDE場合、これらの列に基づいてクエリを実行するためにインデックスレイアウトを最適化する必要がないことをエンジンに伝える句を追加します（これにより、これらの列に対する更新を高速化できます） 。インデックススキャンは、フィルタリング句のないクエリからも発生する可能性SELECT col2 FROM exampletableがあります。テーブルページの代わりにこのサンプルインデックスをスキャンします。
インデックスシーク（行ルックアップの有無にかかわらず）：シークでは、インデックスのすべてが考慮されるわけではありません。クエリの場合SELECT * FROM exampletable WHERE c1 BETWEEN 1234 AND 4567、クエリエンジンは、インデックスでツリーベースの検索を行うことで一致する最初の行を見つけることができ、c1その後、範囲の最後に到達するまでインデックスを順番にナビゲートできます（これはクエリでも同じですというのはc1=1234、=操作であっても条件に一致する行が多数存在する可能性があるためです）。これは、インデックス（またはテーブル）内のすべてのページではなく、関連するインデックスページ（および最初の検索に必要ないくつか）だけを読み取る必要があることを意味します。
クラスター化インデックス：クラスター化インデックスでは、テーブルデータは個別のヒープ構造ではなく、そのインデックスのリーフノードに格納されます。これは、必要な列に関係なく、そのインデックスを使用して行を検索した後、余分な行ルックアップが必要ないことをTEXT意味しVARCHAR(MAX)ます（列や長いデータを含む列などのページ外データがない限り）。
あなたは、これだけの理由で1つのクラスタ化インデックスを持つことができます[1] 、クラスタ化インデックスがある代わりに、別のヒープ構造を有するのあなたのテーブル、あなたがいずれかを使用する場合は、[2]あなたは最大ゲインを得るために慎重にそれを置く場所を選びました。
また、クラスタ化インデックスはテーブルの「クラスタ化キー」であり、テーブル上のすべての非クラスタ化インデックスに含まれているため、一般的に、ワイドクラスタ化インデックスはお勧めできません。
[1]実際には、テーブル上のすべての列をカバーまたは含む非クラスター化インデックスを定義することにより、複数のクラスター化インデックスを効果的に作成できますが、これはスペースを浪費する可能性があり、書き込みパフォーマンスに影響を与える可能性があります。本当に必要です。
[2]「クラスター化インデックスを使用する場合」と言うとき、一般的に各テーブルに1つを作成することをお勧めします。すべての経験則と同様に、例外があります。バルク挿入と順序なし読み取り（ETLプロセスのステージングテーブル）以外はほとんど見られないテーブルは、最も一般的な反例です。
追加ポイント：不完全なスキャン：
クエリの残りの部分によっては、テーブル/インデックススキャンが実際にテーブル全体をスキャンしない場合があることを覚えておくことが重要です。ロジックでクエリプランが許可されている場合、早期に中止することができます。これの最も簡単な例はSELECT TOP(1) * FROM HugeTable、そのクエリプランを見ると、スキャンから1行のみが返されたSET STATISTICS IO ON; SELECT TOP(1) * FROM HugeTableことがわかります。また、IO統計（）を見ると、非常に小さな数しか読み取っていないページの（おそらく1つだけ）。
データのソースであるスキャンと同時にWHEREor JOIN ... ON句の述部を実行できる場合も同じことが起こります。クエリプランナー/ランナーは、この方法でスキャンを早期に終了できるように、述部をデータソースにプッシュすることについて非常に賢い場合があります（そして、そうするのを助けるためにクエリを並べ替えることが賢い場合があります！）。しながら、データが標準クエリプラン表示の矢印に従って右から左へ流れて、ロジックは、左から右へ実行され、次を開始する前に（右から左）の各ステップは、必ずしも完了するまで実行されません。上記の簡単な例では、クエリプランの各ブロックをエージェントとして見ると、エージェントはSELECTエージェントにTOP行を要求し、エージェントは行を要求します。TABLE SCANエージェントはSELECT別のエージェントを要求しますが、別のエージェントを要求しTOPますが、テーブルリーダーに問い合わせる必要がないことをエージェントは認識し、SELECTエージェントは「関連性がなくなりました」という応答を受け取り、すべての作業が完了したことを認識します。多くの操作は、テーブル/インデックス・スキャンは、実際より複雑な例ではそれほど頻繁に当然の最適化のこの種のを阻止んすべての行を読みますが、任意のスキャンは高価な操作でなければならないという結論にジャンプしないように注意してください。