理論的なSQLServer2008の質問：
大量の「空き」メモリを使用してSQLServerでテーブルスキャンを実行した場合、そのテーブルスキャンの結果はメモリに保持されるため、テーブルのインデックスによってもたらされる可能性のある効率が無効になりますか？
更新1：問題のテーブルには、約 テーブルごとに100〜200レコード（各行の平均サイズはわかりません）なので、ここでは大規模なテーブルについては説明していません。
この参照データにmemcached/AppFabric Cacheソリューションを導入することについてクライアントに話しましたが、現時点では範囲外であり、リスクが最小限の「クイックウィン」を探しています。
スキャンで読み取られたすべてのページはバッファプールに読み込まれ、キャッシュエビクションポリシーに従ってメモリプレッシャーの下でのみ解放されます。
しかし、それがテーブルのインデックスによってもたらされる可能性のある効率を打ち消すと思う理由はわかりません。
インデックスは、読み取る必要のあるページがはるかに少ないことを意味する可能性があり、すべてのページがすでにキャッシュにある場合でも、物理的な読み取りは必要なく、論理的な読み取りの数を減らすことは良いことです。論理読み取りは無料ではありません。ページをロックして読み取るためのオーバーヘッドがまだあります。
パフォーマンスの問題に加えて（すべてのページがメモリ内にある場合でも、スキャンはかなりのサイズのテーブルでのインデックスシークよりも何倍も遅くなります）、追加の問題があります：競合。
スキャンの問題は、すべての操作ですべての行にアクセスする必要があることです。これは、すべての選択が挿入/更新/削除の背後でブロックされることを意味します（これらの操作によってロックされた行にアクセスすることが保証されているため）。SELECTは、DMLが毎回コミットするのを待機する必要があるため、基本的に操作のシリアル化と大きな遅延が発生します。穏やかな同時実行性の下でも、効果は全体的に遅く、応答が遅くなります。インデックスを使用すると、現在の操作は対象範囲内の行のみを調べます。これは、単純な確率により、競合の可能性を減らします。その結果、非常に活気があり、応答性が高く、待ち時間の短いシステムになります。
全表スキャンも、データが大きくなるにつれてスケーラブルではありません。とても簡単です。より多くのデータがテーブルに追加されると、全表スキャンは完了するためにより多くのデータを処理する必要があるため、より時間がかかります。また、ディスクとメモリの要求が増え、機器にさらに負担がかかります。全表スキャンが実行される1,000,000行のテーブルについて考えてみます。SQL Serverは、8Kデータページの形式でデータを読み取ります。各ページに保存されるデータの量はさまざまですが、この例では、平均して50行のデータがこれらの8Kページのそれぞれに収まると仮定します。データのフルスキャンを実行してすべての行を読み取るために、20,000のディスク読み取り（1,000,000行/ページあたり50行）。これは、この1つのクエリだけで、処理する必要のある156MBのデータに相当します。本当に超高速のディスクサブシステムがない限り、そのすべてのデータを取得して処理するには、しばらく時間がかかる場合があります。ここで、このテーブルのサイズが毎年2倍になると仮定します。来年、同じクエリが完了するために312MBのデータを読み取る必要があります。
plsはこのリンクを参照します-http ://www.datasprings.com/resources/articles-information/key-sql-performance-situations-full-table-scan