私の質問は、SQLサーバテーブルのパフォーマンスに関するものです。テーブルに多数のカラムがある場合のSQLサーバのパフォーマンス
私は、多くの列、たとえば30列、1列のインデックスを持つテーブルがあると仮定します。この表には約30,000行があります。
私は、インデックス付きの列、および1つ以上を選択し、その選択を行う場合は、例えば、この：
SELECT IndexedColumn, column1
FROM table
は、これが唯一の2列を持つテーブルの上に同じ選択を行い、そして行うよりも遅くなりますa SELECT * ...
基本的に、余分な列からデータを取得していない場合、余分な列が存在するとselectクエリイベントが遅くなりますか？
エンドクライアント（SSMSまたは他のアプリケーションのいずれか）の残りの情報を印刷/渡す必要がないので、プロセスの最後に少し違いがあります。
クラスタ化インデックスに基づいて読み込みを実行すると（BLOBなしの）すべての列が同じページセットに保存されるため、同じページセットにアクセスする必要があるデータを読み取ることができます。
列リストにノンクラスタード・インデックスを配置すると、データ・ページの独自の構造に保存されるので、パフォーマンスが向上します（読み取りにくくなります）。
両方のシナリオのテーブルでプライマリキーを定義するときにSQLサーバーによって作成されるデフォルトのクラスタードインデックスを使用していると仮定した場合、これらの2つのシナリオでパフォーマンスに違いはありません。おそらくそれをチェックアウトし、あなた自身のために実際の実行計画を生成するだけの価値がありますか？ - 実際には上記が真であるとは限りません。これは行ストアであるため、最初のテーブルは各ページに多くの行を収めることができないため、データを読み込む際にIO /ディスクのオーバーヘッドが増えます。
'column1'がインデックスの一部でない場合、' WHERE'を持たない 'SELECT'はそのインデックスをまったく使用しません。それはクラスタード・インデックスを使用する必要があります。そうでなければ、30列のクラスタード・インデックスをスキャンする方が2の1つをスキャンするよりも遅くなります。そうでなければ、おそらく無視できる時間で30,000行をスキャンします。気付きにくい1秒間に何回もすべての行を選択しています。 'column1' *があなたのインデックスの一部である（つまり、それをカバーしている）場合、クラスタード・インデックスはヒットせず、テーブルのカラム数は無関係です。 'INCLUDE'を考えてみましょう。 –
エリック・リッペルト（Eric Lippert）は、[パフォーマンス暴言]（https://ericlippert.com/2012/12/17/performance-rant/） –