「SELECT *」が原則禁止される理由とは？パフォーマンスを高めるSQLの書き方

SQLを書く際、手軽さから「SELECT *」を使いがちですが、実務では「selectのアスタリスクは利用禁止」というルールが一般的です。なぜ便利なのに避けるべきなのでしょうか？

本記事では、パフォーマンス低下や予期せぬエラーを招く理由を深掘りし、保守性を高める具体的な書き方を解説します。この記事を読めば、現場で評価される効率的で堅牢なSQL設計スキルが身につき、システムのトラブルを未然に防げるようになります。

記事のポイント

• 不要なデータの取得を避けることで、ネットワーク帯域やメモリの負荷を減らしシステム全体の動作を高速化できます。
• カラム名を明示することで、将来的なテーブル構造の変更に伴うアプリケーションの予期せぬエラーやバグを防げます。
• 必要な列のみを指定すればインデックスの効果を最大限に引き出せるため、検索パフォーマンスが劇的に向上します。
• 開発時のデバッグなど例外的な場面を除き、本番コードでは列指定を徹底することが保守性を高める基本です。
• ORMを使用する場合でも背後で発行されるSQLを意識し、最適なクエリを設計する習慣がエンジニアとしての信頼に繋がります。

SELECTアスタリスク（*）の使用が推奨されない3つの理由

データベース開発において、 SELECT * は全てのカラムを一度に取得できる便利な記述です。しかし、実務のシステム開発や運用においては、原則として使用を控えるべきだとされています。その主な理由は、 「パフォーマンスの低下」 と 「システムの保守性（メンテナンス性）の低下」 という2つの側面に集約されます。

具体的にどのようなリスクがあるのか、代表的な3つの理由を解説します。

不要なデータ取得によるネットワーク帯域とメモリの圧迫

SQLでアスタリスクを使用すると、その時点でテーブルに含まれる全てのカラムを取得します。これには、その処理では 本来必要のないデータ も含まれてしまいます。

• ネットワーク帯域の浪費：データベースサーバーからアプリケーションサーバーへ送られるデータ量が増大し、ネットワークの転送速度に悪影響を及ぼす可能性があります。
• メモリの消費：取得したデータはアプリケーション側のメモリ上に展開されます。特に、大容量のテキスト型（TEXT）やバイナリ型（BLOB）が含まれるテーブルでアスタリスクを使用すると、メモリを過度に圧迫し、 システムの安定性を損なう恐れ があります。

テーブル定義変更に伴うアプリケーションの予期せぬエラー

テーブルの構造は、システムの成長に合わせて変更されることが多々あります。アスタリスクを使用していると、こうした 「テーブル定義の変更」 が原因でプログラムが停止するリスクが高まります。

特に、 INSERT INTO ... SELECT * のような構文を用いている場合、列の数や順番が一つ変わるだけで致命的なエラーにつながる可能性があるため、注意が必要です。

Kindle Unlimited

IT専門書も30日間無料で読み放題

1冊数千円する専門書から、ビジネス書、実用書、雑誌まで幅広いジャンルが定額で読み放題。ITスキルの向上はもちろん、日々の情報収集や教養を深めるのにも最適です。

• 📚 技術書も月額定額で読み放題
• 📱 マルチデバイス対応
• ✨ 30日間の無料体験

無料で30日間試してみる

インデックスの恩恵を受けられないことによる検索速度の低下

SQLの実行速度を最適化する手法の一つに、 「カバリングインデックス」 があります。これは、検索に必要なカラムがすべてインデックス内に含まれている場合に、テーブル本体のデータを探しに行かず、インデックスだけで処理を完結させる仕組みです。

1
-- 非効率な例（テーブル全体へのアクセスが発生しやすい）
2
SELECT * FROM users WHERE email = 'test@example.com';
3

4
-- 効率的な例（インデックスのみで処理が完結する可能性がある）
5
SELECT id, user_name FROM users WHERE email = 'test@example.com';

アスタリスクを使用すると、インデックスに含まれていないカラムまで取得しようとするため、データベースは 「インデックスオンリースキャン（カバリングインデックス）」を利用できなくなります。 その結果、テーブルの実データ（データブロック）へのアクセス（キールックアップなど）が強制され、検索パフォーマンスが大幅に低下する原因となります。

パフォーマンスと保守性を両立させるSQL設計の具体例

SQLのアンチパターンを避け、効率的なシステムを構築するためには、具体的な書き方のルールを設けることが重要です。ここでは、実務で推奨される設計手法を紹介します。

必要なカラムのみを明示的に指定する「列指定」の徹底

基本原則は、 「その画面や処理で本当に必要な列だけを記述する」 ことです。これにより、データの転送量を最小限に抑え、プログラムの可読性を高めることができます。

1
-- 推奨される書き方：必要なカラムを個別に列挙する
2
SELECT
3
  user_id,
4
  user_name,
5
  email
6
FROM
7
  users
8
WHERE
9
  status = 'active';

列を明示することで、将来的にテーブルへ新しいカラムが追加されたとしても、アプリケーション側のメモリ消費量やデータ受け取り処理に予期せぬ影響を与えにくくなると考えられます。

カバリングインデックスを活用した高速なデータ取得

特定のカラムのみを指定することで、 「カバリングインデックス」 の効果を最大限に引き出せる可能性が高まります。

アスタリスクを使用しないことは、単に「無駄を省く」だけでなく、データベースの機能をフルに活用するための必須条件といえます。

SELECTアスタリスクの使用が許容される特殊なケース

原則禁止とされる SELECT * ですが、以下のような場面では例外的に許容されるケースもあります。

• アドホックな分析 ：運用保守などで、データの中身を一時的に確認するデバッグ作業。
• EXISTS句内 ： WHERE EXISTS (SELECT * FROM ...) のように、存在チェックのみが目的の場合（多くのRDBMSで実行計画が最適化されます）。
• 開発初期のプロトタイプ ：スキーマが頻繁に変わる極めて初期の段階。

ただし、これらはあくまで「一時的」または「特殊」な用途に限定されるべきであり、本番環境のソースコードとして長期的に維持するのは避けるのが望ましいでしょう。

SELECTアスタリスク禁止ルールのまとめとFAQ

今回のまとめ：振り返りチェックリスト

• ネットワーク帯域やメモリの節約だけでなく、インデックスの効果を最大化するために「必要な列だけ」を取得する習慣をつける
• テーブル定義の変更による予期せぬエラーを防ぎ、将来の自分やチームメンバーが安心してメンテナンスできるコードを目指す
• デバッグや一時的な分析では効率を優先してアスタリスクを使いつつ、本番環境のコードでは「列指定」を徹底するという使い分けを意識する
• アドバイス： 次のコードレビューやプルリクエスト作成の際に、不要なアスタリスクが紛れ込んでいないか一箇所だけでも確認してみましょう！こうした小さな積み重ねが、高負荷にも耐えられる堅牢なシステム作りへと繋がります。

SQL開発において SELECT * を避けることは、単なる慣習ではなく、システムの パフォーマンス向上 と 保守性の確保 に直結する重要なプラクティスです。これまでのポイントを振り返り、実務で活用できるチェックリストとよくある疑問を整理しました。

コードレビューで役立つクエリ改善チェックリスト

チーム内でのコードレビューやセルフチェックの際、以下の項目を確認することをおすすめします。

SELECTアスタリスクに関するよくある質問（FAQ）

現場でよく挙がる疑問について回答します。

Q. アドホックな分析やデバッグでの使用も禁止すべきですか？

手元のツールでデータの中身を一時的に確認するような、使い捨てのクエリであれば SELECT * を使用しても問題ないと考えられます。ただし、本番環境のソースコードや、自動実行されるバッチ処理などに組み込むのは避けるのが望ましいでしょう。

Q. カラム数が多いテーブルで列指定を効率化する方法はありますか？

すべてのカラムを手動でタイピングするのは手間がかかります。多くのデータベース管理ツール（GUIツール）には、テーブルから カラム名を自動生成する機能 が備わっています。また、以下のようなSQLを実行してシステムカタログからカラム一覧を取得し、エディタに貼り付ける方法も効率的です。

1
-- カラム名の一覧を取得する例（MySQLの場合）
2
SELECT COLUMN_NAME
3
FROM INFORMATION_SCHEMA.COLUMNS
4
WHERE TABLE_NAME = 'テーブル名'
5
ORDER BY ORDINAL_POSITION;

このようにツールやメタデータを活用することで、正確かつスピーディーに列指定のSQLを記述できる可能性があります。

参考文献

• SELECT (Transact-SQL) - Microsoft Learn
• MySQL 8.0 リファレンスマニュアル - 13.2.13 SELECT ステートメント
• PostgreSQL 16.0 文書 - SELECT

SQL活用者にお勧めの本

おすすめ

スッキリわかるSQL入門 第4版 ドリル256問付き！ スッキリわかるシリーズ

Amazonで詳細を見る 🔴 楽天で見る

センスの良いSQLを書く技術　達人エンジニアが実践している３５の原則

Amazonで詳細を見る 🔴 楽天で見る

初心者向け

SQL1年生 データベースのしくみ SQLiteで体験してわかる！会話でまなべる！

Amazonで詳細を見る 🔴 楽天で見る