SQLクエリが制限されている場合と行全体を呼び出す場合のパフォーマンスの利点

Question

行全体をクエリするのではなく、クエリで必要なフィールドのみを選択することにより、パフォーマンス上の利点はどれくらいありますか？たとえば、10個のフィールドの行があり、ディスプレイに5個のフィールドのみが必要な場合、それらの5個だけを照会する価値はありますか？この制限によるパフォーマンス上のメリットと、必要に応じて後でSQLクエリにフィールドを追加し直す必要があるリスクとの違いは何ですか？

Answer 1

考慮する必要があるのは、単なるデータの側面だけではありません。すべての列を選択すると、クラスター化インデックス（またはテーブル）へのブックマーク検索が必要になるため、インデックスをカバーする有用性が無効になります。

Answer 2

選択される行数、およびこれらの追加フィールドが消費するメモリ量によって異なります。たとえば、複数のテキスト/ブロブフィールドが存在する場合、または多数の行が選択されている場合、実行速度が大幅に低下する可能性があります。

後でフィールドを追加するのはリスクですか？要件の変化に合わせてクエリを変更することは、開発プロセスの自然な部分です。

Answer 3

selectステートメントで明示的に列に名前を付けることの唯一の利点は、コードで使用している列の名前が変更されると、コードの前にselectステートメントが失敗することです。 selectステートメントがproc内にある場合、さらに良いことに、procとDBスクリプトはコンパイルされません。これは、VS DBエディションなどのツールを使用してDBスクリプトをコンパイル/検証する場合に非常に便利です。 それ以外の場合、パフォーマンスの違いは無視できます。

Answer 4

取得されるフィールドの数は、SQLリクエスト自体の大きなオーバーヘッドに関連するパフォーマンスへの2次の影響です。プロセスから出て、ネットワークを介して別のホストに移動し、場合によってはそのホストのディスクにさらに多くのサイクルがかかります余分な数バイトのデータをシャベルするよりも。

明らかに、余分なフィールドにメガバイトのblobが含まれる場合、方程式は歪められます。しかし、私の経験では、トランザクションのオーバーヘッドは、実際のデータを取得した場合と同じかそれ以上です。私は何年も前から「空」よりも漠然と覚えています。 NOP TNS要求は、ワイヤ上で約100バイトです。

Answer 5

SQLサーバーがクエリを実行しているマシンと異なる場合、追加の列を選択すると、ネットワークからより多くのデータが転送されます（ボトルネックになる可能性があります）。ディスクからより多くのデータを読み取る必要があることを忘れないでください、結果を保持するためにより多くのメモリを割り当てます。

それ自体で問題を引き起こすものはありませんが、合計するとパフォーマンスの問題が発生します。クエリまたはデータのいずれかがたくさんある場合、少しずつ役立ちます。

私が推測するリスクは、後でクエリにフィールドを追加する必要があり、コードを変更することを意味する可能性がありますが、通常は追加のフィールドを処理するためにコードを追加する必要があります。