select * vs select column

2/3列が必要なだけSELECT *で、それらの列を選択クエリで提供する代わりにクエリを実行する場合、I / Oまたはメモリの増減に関するパフォーマンスの低下はありますか？

必要なく*を選択すると、ネットワークオーバーヘッドが発生する可能性があります。

しかし、選択操作では、データベースエンジンは常にディスクからアトミックタプルをプルするのですか、それとも選択操作で要求された列のみをプルするのですか？

常にタプルをプルする場合、I / Oオーバーヘッドは同じです。

同時に、タプルをプルする場合、要求された列をタプルから取り除くためにメモリが消費される可能性があります。

その場合、select someColumnはselect *よりも多くのメモリオーバーヘッドを持ちます。

常にタプルをプルします（テーブルが垂直にセグメント化されている場合を除き、列の断片に分割されます）。したがって、あなたが尋ねた質問に答えるには、パフォーマンスの観点からは問題ではありません。ただし、他の多くの理由から（以下）、必要な列は常に名前で具体的に選択する必要があります。

（私がよく知っているすべてのベンダーのRDBMSで）すべて（テーブルデータを含む）の基礎となるディスク上のストレージ構造は、定義されたI / Oページに基づいている ため（SQL Serverでは、たとえば、各ページは8キロバイト）。そして、すべてのI / O読み取りまたは書き込みはページごとです。つまり、すべての書き込みまたは読み取りは、データの完全なページです。

この根本的な構造上の制約のため、結果として、データベース内のデータの各行は常に1つのページにのみ存在する必要があります。データの複数のページにまたがることはできません（実際のblobデータが個別のページチャンクに格納され、実際のテーブル行の列がポインターのみを取得するblobなどの特別なものを除く）。ただし、これらの例外は単なる例外であり、特別な場合（特別なタイプのデータ、または特別な状況に対する特定の最適化）を除いて、通常は適用されません。
これらの特別な場合でも、通常、実際のデータのテーブル行自体（ Blobなどの実際のデータへのポインター）、それは単一のIOページに保存する必要があります...

例外。Select *OKである唯一の場所は、次のように、Existsor Not Exists述語句の後のサブクエリです。

   Select colA, colB
   From table1 t1
   Where Exists (Select * From Table2
                 Where column = t1.colA)

編集：@マイクシェラーのコメントに対処するために、はい、それは技術的に、あなたの特別なケースのための少しの定義で、そして審美的に両方とも真実です。まず、要求された列のセットがインデックスに格納されている列のサブセットである場合でも、クエリプロセッサは、同じ理由で、要求された列だけでなく、そのインデックスに格納されているすべての列をフェッチする必要があります。すべてのI / Oは、ページとインデックスデータは、テーブルデータと同じようにIOページに保存されます。したがって、インデックスに格納された列のセットとしてインデックスページの「タプル」を定義した場合でも、ステートメントは真になります。
要点ではなく、I / Oページに格納されているものに基づいてデータをフェッチすることがポイントであり、ベーステーブルのI / Oページとインデックスのどちらにアクセスしているかに関係なく、ステートメントは審美的に真実ですI / Oページ。

を使用しないその他の理由についてはSelect *、「有害とSELECT *見なされる理由」を参照してください 。：

SELECT *本番用コードで使用してはならない（決してしない）理由はいくつかあります。

• データベースに必要なヒントを与えていないため、最初にテーブルの定義を確認して、そのテーブルの列を特定する必要があります。そのルックアップにはある程度の時間がかかります-単一のクエリではそれほどではありません-しかし、時間の経過とともに増加します

• 列の2/3だけが必要な場合は、ディスクから取得してネットワーク経由で送信する必要があるデータの1/3が多すぎます

• 返される列の順序など、データの特定の側面に依存し始めた場合、テーブルが再編成されて新しい列が追加された（または既存の列が削除された）場合、厄介な驚きが生じる可能性があります。

• SQL Server（他のデータベースについては不明）では、列のサブセットが必要な場合、非クラスター化インデックスがその要求をカバーしている可能性があります（必要なすべての列が含まれています）。を使用するとSELECT *、最初からその可能性をあきらめています。この特定のケースでは、データはインデックスページから取得され（必要な列がすべて含まれている場合）、クエリを実行する場合と比較して、ディスクI / O とメモリのオーバーヘッドははるかに少なくなりSELECT *....ます。

はい、最初は少しタイプする必要があります（SQL ServerのSQLプロンプトのようなツールはそこでも役立ちます）-しかし、これは例外がないルールがある実際の1つのケースです：プロダクションコードでSELECT *を使用しないでください。これまで。

あなたは、必要があり、常に唯一selectの列あなたが実際に必要とすること。選択する量を増やすのではなく少なくすることは決して効率的ではありません。また、クライアント側の結果列にインデックスでアクセスし、新しい列をテーブルに追加することでこれらのインデックスが正しくなくなるなど、予期しない副作用も少なくなります。

[編集]：アクセスを意味します。愚かな脳がまだ目を覚ます。

大きなblobを保存しているのでない限り、パフォーマンスは問題になりません。SELECT *を使用しない主な理由は、返された行をタプルとして使用している場合、スキーマが指定した順序で列が返されるためです。その場合、すべてのコードを修正する必要があります。

一方、辞書形式のアクセスを使用する場合、常に名前でアクセスするため、列がどの順序で返されるかは関係ありません。

これはすぐに、私が使用していたタイプの列を含むテーブルを思い起こさせますblob。通常は数Mb秒のJPEG画像が含まれていました。

言うまでもありませんがSELECT、本当に必要な場合を除いて、このコラムを省略しました。特に複数の行を選択した場合は、そのデータをフロートさせるのは面倒でした。

ただし、通常はテーブルのすべての列を照会することを認めます。

SQLの選択中、DBはSELECT a、b、cのSELECT *であるかどうかに関係なく、常にテーブルのメタデータを参照します。なぜですか？システム上のテーブルの構造とレイアウトに関する情報がそこにあるためです。

この情報を読まなければならない理由は2つあります。1つは、ステートメントをコンパイルするだけです。少なくとも既存のテーブルを指定することを確認する必要があります。また、最後に文が実行されてからデータベース構造が変更されている可能性があります。

さて、明らかに、DBメタデータはシステムにキャッシュされますが、実行する必要があるのはまだ処理中です。

次に、メタデータを使用してクエリプランが生成されます。これは、ステートメントがコンパイルされるたびにも発生します。繰り返しますが、これはキャッシュされたメタデータに対して実行されますが、常に実行されます。

この処理が行われないのは、DBが事前にコンパイルされたクエリを使用しているか、以前のクエリをキャッシュしている場合のみです。これは、リテラルSQLではなくバインディングパラメータを使用するための引数です。「SELECT * FROM TABLE WHERE key = 1」は「SELECT * FROM TABLE WHERE key =？」とは異なるクエリです。「1」はコールにバインドされています。

DBはそこでの作業をページキャッシングに大きく依存しています。最近のDBの多くは、メモリに完全に収まるほど小さい（または、おそらく、現代のメモリは、多くのDBに収まるほど大きい）です。次に、バックエンドでの主なI / Oコストは、ロギングとページフラッシュです。

ただし、DBのディスクを使用している場合、多くのシステムで行われる主な最適化は、テーブル自体ではなく、インデックス内のデータに依存することです。

あなたが持っている場合：

CREATE TABLE customer (
    id INTEGER NOT NULL PRIMARY KEY,
    name VARCHAR(150) NOT NULL,
    city VARCHAR(30),
    state VARCHAR(30),
    zip VARCHAR(10));

CREATE INDEX k1_customer ON customer(id, name);

次に、 "SELECT id、name FROM customer WHERE id = 1"を実行すると、DBがこのデータをテーブルからではなく、インデックスからプルする可能性が非常に高くなります。

どうして？とにかく、クエリを満たすためにインデックスを使用します（テーブルスキャンに対して）。また、where句で 'name'が使用されていなくても、そのインデックスはクエリにとって最良のオプションです。

これで、データベースにはクエリを満たすために必要なすべてのデータが揃ったので、テーブルページ自体をヒットする必要はありません。インデックスを使用すると、一般的にテーブルと比べてインデックスの行密度が高くなるため、ディスクトラフィックが減少します。

これは、一部のデータベースで使用されている特定の最適化手法についての波状の説明です。多くの場合、いくつかの最適化およびチューニング手法があります。

最後に、SELECT *は、手動で入力する必要がある動的クエリに役立ちます。「実際のコード」には使用しません。個々の列の識別により、クエリを最適化するために使用できるより多くの情報がDBに提供され、スキーマの変更などに対するコードの制御が向上します。

アプリを維持するためのパフォーマンスと機能は熟考されているため、質問に対する正確な回答はないと思います。Select columnはより高性能select *ですが、指向のオブジェクトシステムを開発している場合は、使用object.propertiesを好み、アプリの任意の部分でプロパティが必要になる可能性があります。そうでない場合は、特別な状況でプロパティを取得するためのメソッドをさらに記述する必要があります。select *すべてのプロパティを使用して入力します。アプリは、使用して良いパフォーマンスを持っている必要があり、select *場合によっては、select columnを使用してパフォーマンスを改善する必要があります。次に、パフォーマンスが必要なときにアプリとパフォーマンスを作成および維持するための2つの世界のどちらかを使います。

ここで受け入れられた答えは間違っています。これの複製として別の質問が閉じられたときにこれに遭遇しました（私がまだ私の答えを書いている間に-grr-したがって、以下のSQLは他の質問を参照しています）。

常にSELECT属性、attribute ...を使用する必要があります。

それは主にパフォーマンスの問題のためです。

ユーザーから名前を選択WHERE name = 'John';

あまり便利な例ではありません。代わりに検討してください：

SELECT telephone FROM users WHERE name='John';

（name、telephone）にインデックスがある場合、テーブルから関連する値を検索する必要なくクエリを解決できます- カバリングインデックスがあります。

さらに、テーブルにユーザーの写真を含むBLOB、アップロードされたCV、およびスプレッドシートがあるとします。SELECT*を使用すると、この情報がすべてDBMSバッファーに戻されます（キャッシュから他の有用な情報を強制的に取り出します）。次に、ネットワークの稼働時間と冗長なデータ用のクライアントのメモリを使用して、すべてクライアントに送信されます。

また、クライアントが列挙型配列（PHPのmysql_fetch_array（$ x、MYSQL_NUM）など）としてデータを取得した場合、機能上の問題が発生する可能性もあります。多分、コードが「telephone」と書かれたとき、SELECT *によって返される3番目の列でしたが、誰かがやって来て、「telephone」の前に配置されたテーブルに電子メールアドレスを追加することにしました。目的のフィールドが4列目に移動します。

どちらの方法でも物事を行うには理由があります。私はPostgreSQLでSELECT *をよく使用します。これは、PostgreSQLでSELECT *を使用して実行できる多くのこと、特にストアドプロシージャでは明示的な列リストを使用して実行できないためです。同様に、Informixでは、継承されたテーブルツリーに対するSELECT *を使用すると、ぎざぎざの行が表示されますが、子テーブルの追加の列も返されるため、明示的な列リストは表示されません。

PostgreSQLでこれを行う主な理由は、テーブルに固有の整形式を確実に取得できるためです。これにより、結果を取得してPostgreSQLのテーブルタイプとして使用できます。これにより、固定列リストよりも多くのオプションをクエリで使用できます。

一方、厳密な列リストは、dbスキーマが特定の方法で変更されていないことをアプリケーションレベルで確認できるため、これが役立ちます。（私は別のレベルでそのようなチェックを行います。）

パフォーマンスについては、VIEWと、タイプを返すストアドプロシージャ（およびストアドプロシージャ内の列リスト）を使用する傾向があります。これにより、返されるタイプを制御できます。

ただし、通常はSELECT *をベーステーブルではなく抽象化レイヤーに対して使用していることに注意してください。

この記事から引用したリファレンス：

SELECT *なし： その時点で” SELECT *”を使用している場合、データベースからさらに列を選択しており、この列の一部はアプリケーションで使用されない可能性があります。これにより、追加のコストとデータベースシステムの負荷が発生し、より多くのデータがネットワーク上を移動します。

SELECT *を使用する 場合：特別な要件があり、列を追加または削除するときに動的環境を作成した場合、アプリケーションコードによって自動的に処理されます。この特別なケースでは、アプリケーションとデータベースのコードを変更する必要はありません。これは、本番環境に自動的に影響します。この場合、「SELECT *」を使用できます。

ここに表示されていないディスカッションにニュアンスを追加するだけです：I / Oに関して、列指向のストレージを備えたデータベースを使用している場合、特定のクエリのみを実行すれば、I / Oを大幅に削減できます。列。SSDに移行すると、行指向のストレージと比較して、メリットは少し小さくなる可能性がありますが、a）気になる列を含むブロックのみを読み取るb）圧縮により、一般にディスク上のデータのサイズが大幅に削減されるため、ディスクから読み取られたデータの量。

列指向のストレージに慣れていない場合、Postgresの実装の1つはCitus Dataによるもの、別の実装はGreenplum、別のParaccel、別の（大まかに言えば）Amazon Redshiftです。MySQLにはInfobrightがあり、これは今ではほとんど機能していないInfiniDBです。その他の商用製品には、HPのVertica、Sybase IQ、Teradata ...などがあります。

select * from table1 INTERSECT  select * from table2

等しい

select distinct t1 from table1 where Exists (select t2 from table2 where table1.t1 = t2 )