全項目をselectする場合「select *」と「select カラム1 カラム2 ･･･」のパフォーマンスは違うのか?

Question

DB2での質問になります。(DB2に固有な話とは思えませんが)
質問内容はタイトルのとおりなのですが、全項目を取得しなければならないselectの場合、*で引っ張ってくるとパフォーマンスに影響するので全項目をコーディングしなければならないと言われたことがあります。

これって都市伝説でしょうか?

前提：
- カラム数は120程度
- 全レコード数は1000万レコード程度のテーブル
- レコード長800～1000バイト程度
- 一回のselectで20レコード程度取得(さすがにwhereは指定しています)

背景：
- PL/SQLにてカーソル定義でselectをコードしている
- カーソルforループでレコードを取り出して汎用ルーチンにパラメーターで渡している
- 汎用ルーチンのインターフェースとしてパラメーター定義に%ROWTYPEが付加されている
- 上記にてレコードにカラムを追加したらコンパイルでエラーとなり、調べたらカーソルのselectのコーディングにもカラムを追加しなければならないとわかったが、どうしてそこは「select *」しておかないのかと聞いたらタイトルのような理由と言われた
- パフォーマンスはハードが稼ぐものであり、将来の保守によるバグを生まないコードとして「select *」が望ましいのではないかと自分は思ってしまった・・・

Accepted Answer

こんにちは。

知っている限りの話では、`select *` でパフォーマンスが落ちると言われているのは往々にして「意図せず不要な列の取得が行われる場合がある」からであって、現在存在する全ての列を取得するクエリと比較する場合はパフォーマンスに違いはないはずです。
`select *` を使うか全列列挙するかの判断基準はパフォーマンスではなく、テーブルのカラムに変更が加わった際に自然と追従してよいのか、あるいは変更を検出 (エラーになる) できてほしいのかで選ぶものです。

一般には、プログラムというものは特定のカラムの存在を想定して記述するものなので、仮に全列参照する場合でも `select *` は使わない方が良い、というプラクティスのことを言っているのかもしれません。
例えば、仮に今参照しているテーブルから特定の列が削除されたとき、ふんわり動いてほしいのか、即座にエラーで止まってほしいのかを改めて考えてみてください。

逆に言えば、どのように列が変化してもそのまま全てを参照したい、というような特殊な要件下など、`select *` を使う方が適切であるケースもあります。

Answer

レスポンスに関しては推論より、実際に投入される環境の実行計画で確認すべきです。
その上で疑問になる点がある時に質問した方がより効果的です。

特にDB2を利用されている方は他のDBMSより少ないですし。

私は記述を極力少なくする派なので、`*`が使えるなら`*`を使用しますが、ネストが深いSQLなどでは、項目を明示するしかないDBMSもあります。

Answer

> 将来に渡ってすべての列を取得する処理ということで、将来列が追加されたらその列も含めて取得する必要があり、まさに今やっている案件がその話に当たります。

であれば、「select *」と**すべき** だと思います。 全取得が目的ですので、列挙とのパフォーマンスの差はありません。

また、なにしろすべてのカラムの情報が必要であるという意図も「select *」で表現できるので、よりよいと言えるでしょう
ただし、「select * は使うべきでない」という考えの方もいると思うので、コメントに意図的であることを明記しておくのがいいでしょう。

Answer

> DB2での質問になります。

> **全項目を取得しなければならないselect**の場合、*で引っ張ってくるとパフォーマンスに影響するので全項目をコーディングしなければならない

（身も蓋もないですが）「**場合による**」としか言いようがありません。

[Db2 for Linux, UNIX and Windows: 効率的な SELECT ステートメント](https://www.ibm.com/docs/ja/db2/12.1.0?topic=design-efficient-select-statements)

> 効率的な SELECT ステートメントを作成するための、以下の指針を考慮してください。
> - 必要な列だけを指定します。 1 つのアスタリスク (*) を使ってすべての列を指定すると、**不必要な処理が実行されます**。

[Db2 for z/OS: SELECT * の使用による影響](https://www.ibm.com/docs/ja/db2-for-zos/13.0.0?topic=statement-implications-using-select)

> 一般に、SELECT * は、**非表示列以外のすべての列を選択する場合にのみ使用**する必要があります。

> 通常、Db2 が選択した列の数に依存しているため、必要な列のみを選択する必要があります。 SELECT * を使用するのは、**隠し列を除くすべての列を選択する必要があることが確実であるときだけ**にしてください。 (**隠し列は、SELECT * を指定しても戻されません。**) すべての列の選択に代わる方法の 1 つは、必要とする列だけが定義されているビューを使用し、そのビューのアクセスに SELECT * を使用することです。 選択したすべての列がソート操作（SELECT DISTINCTとSELECT…）に参加している場合は、SELECT * を避けてください。例えば、 UNIONなどです。 )

[Db2 for Linux, UNIX and Windows: 隠し列](https://www.ibm.com/docs/ja/db2/12.1.0?topic=concepts-hidden-columns)

> 表列が暗黙的な隠し属性によって定義されると、明示的に参照されなければ、その列は使用できません。 例えば、**SELECT * 照会を表に対して実行した場合、暗黙的な隠し列は結果表に返されません。** 暗黙的な隠し列は、列名を指定できる場所ならどこででも、明示的な方法で参照が可能です。

[Db2 for z/OS: SELECT ステートメントによるデータの取り出し](https://www.ibm.com/docs/ja/db2-for-zos/13.0.0?topic=programs-retrieving-data-by-using-select-statement)

> SELECT * は、**動的 SQL およびビュー定義で使用する場合に最も適しています**。 静的SQLでSELECT * を使用できますが、**ホスト変数の互換性とパフォーマンスへの影響の可能性がある**ため、お勧めしません。 SELECT * が参照表に列を追加するとします。 その列の受信ホスト変数を定義しない場合、エラーが発生するか、追加列のデータが取得されない可能性があります。
> 
> アスタリスクの代わりに、静的SELECT ステートメントに列名をリストすると、SELECT * の発生可能問題を回避できます。 また、受け取りホスト変数と結果表中の列の対応関係を知ることもできます。

Answer

> 将来の保守によるバグを生まないコードとして「select *」が望ましいのではないか

一般に「select *」はパフォーマンスやセキュリティを犠牲にしてデバッグなどテスト用に使うものなので、原則カラム名を列記して使うのが賢明です。