SQL Server 2008 R2 で合計 170 万行のテーブルがあります。
そして、ここに私の懸念があります。プログラムで 1.7 ミルのすべてのレコードを表示する必要があります。私が使用した標準的なアプローチは、
select col1, col2, col3,... , col13 from table
ただし、アプリケーション エンド (VB.NET) では、DataGridView コントロールにすべてのレコードをロードするのに約 1 分かかります。
どういうわけか、ユーザーが表示するのに 1 分間待たなければならないのは良くありません。
ここでの私の質問は、Select Allステートメントを高速化するために考慮すべきアプローチはありますか? 例: 設定、ページングなど?
P/s: 索引付けについていくつか読んだことがあります。私が間違っていなければ、特定のレコードのみの儀式を選択するような状況では、インデックスの方が適していますか?
すべてのアドバイスとヘルプに感謝します!
よろしく、PC
一度にすべての行を返さないことをお勧めします。誰かが各行を見ているでしょうか？
クラスター化されたインデックスは、すべてのデータがインデックス順に物理的に格納されるため、読み取りが高速です。すべての列を読み取るため、クラスター化インデックスが定義されていることを確認してください。
おっしゃる通り、テーブル内の 170 万件のレコードすべてを高速に取得するには、インデックスが役に立ちません。インデックスはルックアップ指向のデータ構造であり、行の属性 (特定の列の値または列の値から計算された式を意味する属性) に基づいて行をより迅速に検索できるようにします。これらは通常、アプリケーションが実行している並べ替えのような完全なテーブル スキャンを回避することを目的として、テーブル内の行を述語に一致する行にすばやくフィルター処理するためのある種のツリー オブジェクトです。
ただし、インデックスは、取得する行数がテーブル内の行の総数よりも大幅に少ない場合にのみ役立ちます。すべての行を表示したい場合、それらはまったく役に立ちません。
申請要件を再検討することをお勧めします。ページをロードするたびにすべての行を取得することが本当に必要ですか? 彼らはそんなに頻繁に変わりますか？データベースとアプリケーションの間に何らかの NoSQL キャッシュ レイヤーを配置できますか? Memcached を使用すると、おそらくこれが大幅に高速化される可能性があります。
また、アプリケーションが使用されるたびに、これらの 1.7m の行すべてが本当に必要になると仮定しています。あなたは彼らと何をしていますか？