SQLを学び始めた際、最初に覚えるのが「SELECT *」という記述ではないでしょうか。

アスタリスク記号は、テーブルに含まれるすべての列を一度に取得できる非常に便利なワイルドカードです。

しかし、実務の現場や大規模なシステム開発において、アスタリスクを無条件に使用することは推奨されません。

この記事では、SQLにおけるアスタリスクの基本的な役割から、使用するメリット・デメリット、そしてなぜプロダクション環境で避けるべきなのかを詳しく解説します。

最新のデータベース設計のトレンドを踏まえ、パフォーマンスやメンテナンス性に優れたクエリの書き方を身につけましょう。

目次 [ close ]
  1. SQLのアスタリスク（*）の基本概要
    1. SELECT文での基本的な使い方
    2. COUNT(*)での活用
  2. アスタリスクを使用するメリット
    1. 開発スピードの向上
    2. スキーマの変更に柔軟に対応できる（調査時）
  3. プロダクション環境でアスタリスクを避けるべき5つの理由
    1. 1. ネットワークとメモリのトラフィック増加
    2. 2. データベースの実行計画とインデックスの効果低下
    3. 3. スキーマ変更によるアプリケーションの破損
    4. 4. コードの可読性とメンテナンス性の低下
    5. 5. セキュリティ上のリスク
  4. 実戦的なコード比較と推奨される書き方
    1. アンチパターンの例（アスタリスク使用）
    2. 推奨される例（列名の明示）
  5. アスタリスクの使用が許容される場面
    1. EXISTS句の中での使用
    2. 一時的なデータ確認やデバッグ
  6. アスタリスク利用 vs 列名指定の比較表
  7. より高度なテクニック：EXCLUDEとREPLACE（2026年のトレンド）
  8. まとめ

SQLのアスタリスク（*）の基本概要

SQLにおけるアスタリスク（*）は、「すべての列（カラム）」を指定するための特殊記号です。

通常、SELECT文では取得したい列の名前をカンマ区切りで指定しますが、アスタリスクを使うことでその手間を省くことができます。

SELECT文での基本的な使い方

最も一般的な使い方は、特定のテーブルから全データを抽出する場合です。

例えば、employeesというテーブルの全情報を確認したい場合、以下のように記述します。

SQL
-- 全ての従業員情報を取得する
SELECT * FROM employees;
実行結果
id | name     | department | salary | hired_at
---+----------+------------+--------+-----------
1  | 田中 太郎 | 営業部      | 300000 | 2023-04-01
2  | 佐藤 花子 | 開発部      | 450000 | 2022-10-15
3  | 鈴木 一郎 | 人事部      | 350000 | 2024-01-20

このように、テーブルに定義されているすべての列が順番に出力されます。

列名が10個あっても20個あっても、アスタリスク1つで記述できるため、開発中のデータ確認には非常に適しています。

COUNT(*)での活用

アスタリスクは、集計関数であるCOUNTと組み合わせて使用されることも多いです。

COUNT(*)は、NULL値を含むすべての行数をカウントする際に使用されます。

SQL
-- テーブルの全行数を取得する
SELECT COUNT(*) FROM employees;
実行結果
count
-------
3

特定の列名を指定したCOUNT(列名)の場合、その列がNULLである行は除外されます。

そのため、純粋なデータ件数を知りたい場合には、アスタリスクを用いた記述が標準的に使われます。

アスタリスクを使用するメリット

アスタリスクの使用には、特定の場面において明確な利点が存在します。

開発スピードの向上

開発の初期段階や、アドホック（一時的）な分析において、列名をすべて書き出すのは時間がかかります。

特にカラム数が多いテーブルの内容をざっと把握したい場合、アスタリスクは最短のタイピングで結果を得る手段となります。

スキーマの変更に柔軟に対応できる（調査時）

デバッグ作業などで「とにかく今のテーブルの状態をすべて見たい」という場面では、列の追加や削除を気にする必要がありません。

常に最新のテーブル構造に基づいた全データが表示されるため、調査用クエリとしては非常に優秀です。

プロダクション環境でアスタリスクを避けるべき5つの理由

一方で、本番環境のアプリケーションコードに「SELECT *」を記述することは、エンジニアの間で「アンチパターン」とされています。

なぜアスタリスクの使用を控えるべきなのか、その具体的な理由を見ていきましょう。

1. ネットワークとメモリのトラフィック増加

アスタリスクを使用すると、アプリケーションで必要のないデータまで取得してしまいます。

例えば、100個の列を持つテーブルから「ユーザー名」だけが必要な場合でも、残りの99個のデータを転送することになります。

これはネットワーク帯域を無駄に消費し、アプリケーションサーバーのメモリ圧迫に繋がります。

特に画像データや長文テキストを含む列（BLOBやTEXT型）がある場合、パフォーマンスの低下は顕著になります。

2. データベースの実行計画とインデックスの効果低下

データベースエンジンは、クエリを最適化するために実行計画を作成します。

特定の列だけを指定した場合、データベースは「インデックスのみ」を参照して結果を返す「カバリングインデックス」を利用できることがあります。

しかし、アスタリスクを使用すると、ほぼ確実にテーブル本体のデータ（データページ）へアクセスする必要が生じます。

これにより、本来であれば高速に処理できたはずのクエリが、ディスクI/Oの発生によって低速化してしまいます。

3. スキーマ変更によるアプリケーションの破損

アプリケーション側で「1番目の列はID、2番目の列は名前」のように、列の順番（インデックス）に依存した処理を書いている場合にリスクが発生します。

テーブルに新しい列が追加されたり、列の順番が変更されたりすると、アスタリスクで取得されるデータの順序が変わり、プログラムが意図しない動作をしたりクラッシュしたりする原因になります。

列名を明示していれば、列が増えても取得対象は変わらないため、堅牢性が向上します。

4. コードの可読性とメンテナンス性の低下

後からソースコードを読み返した際、「SELECT *」と書かれていると、その処理で実際にどのデータが必要とされているのかが分かりません。

コードの意図を明確にするためには、必要なカラムを明示することで、ドキュメントとしての役割を持たせることが重要です。

5. セキュリティ上のリスク

テーブルには、パスワードハッシュや個人情報、管理用フラグなど、フロントエンドに露出させてはいけない秘匿情報が含まれていることがあります。

アスタリスクでデータを取得していると、うっかりこれらの機密情報をAPIのレスポンスに含めてしまうといった事故が発生しやすくなります。

最小権限の原則に基づき、必要なデータのみを取得する習慣をつけることがセキュリティ対策の第一歩です。

実戦的なコード比較と推奨される書き方

具体的なコード例を通じて、アスタリスクを使用する場合と列名を指定する場合の違いを確認しましょう。

アンチパターンの例（アスタリスク使用）

SQL
-- プロダクションコードとしては非推奨
SELECT * FROM users WHERE user_id = 123;

この記述では、将来的にusersテーブルに巨大なデータ列が追加された際、パフォーマンス劣化の影響をダイレクトに受けます。

推奨される例（列名の明示）

SQL
-- 必要なカラムだけを明確に指定する
SELECT 
    user_id, 
    user_name, 
    email 
FROM users 
WHERE user_id = 123;

このように記述することで、どのデータを使用しているかが一目で分かり、パフォーマンスも最適化されます。

アスタリスクの使用が許容される場面

「アスタリスクは絶対にダメ」というわけではありません。

以下のケースでは、アスタリスクの使用が合理的です。

EXISTS句の中での使用

相関サブクエリなどで存在チェックを行うEXISTS句では、アスタリスクを使用してもパフォーマンスに影響しません。

SQL
-- 注文履歴があるユーザーを抽出する
SELECT user_name 
FROM users u
WHERE EXISTS (
    SELECT * 
    FROM orders o 
    WHERE o.user_id = u.user_id
);

この場合、データベースエンジンは「行が存在するかどうか」だけを判定するため、実際に列データをフェッチ（取得）することはありません。

一時的なデータ確認やデバッグ

データベースクライアントツール（DBeaverやA5:SQL Mk-2など）を使用して、手動でデータを確認する際にはアスタリスクが最も効率的です。

あくまで「人間がその場で見るため」の用途であれば、制限なく活用して良いでしょう。

アスタリスク利用 vs 列名指定の比較表

これまでの内容を整理し、それぞれの違いを比較表にまとめました。

比較項目SELECT * (アスタリスク)SELECT 列名 (明示的指定)
記述の手間非常に少ない列数が多いと手間がかかる
パフォーマンス低い (不要な転送が発生)高い (必要最小限の転送)
保守性低い (依存関係が不明確)高い (どの列を使うか一目瞭然)
インデックス活用困難 (全列取得のため)容易 (カバリングインデックス可能)
推奨シーンデバッグ、データ調査アプリ実装、バッチ処理

より高度なテクニック：EXCLUDEとREPLACE（2026年のトレンド）

2026年現在のモダンなデータウェアハウス（Google BigQueryやDuckDBなど）では、アスタリスクの利便性を活かしつつ欠点を補う構文が普及しています。

それは、「特定の列を除外してすべて取得する」という方法です。

SQL
-- 秘密情報列だけを除外して、それ以外をすべて取得する (BigQueryなどの例)
SELECT * EXCEPT (password_hash, secret_key) 
FROM users;

このような構文を利用することで、アスタリスクの手軽さを享受しながら、セキュリティリスクや転送量の増大を抑えることが可能になっています。

標準的なSQL（PostgreSQLやMySQLなど）ではまだ一般的ではありませんが、分析基盤の構築においては非常に重要なテクニックとなっています。

まとめ

SQLにおけるアスタリスク（*）は、手軽にすべての情報を引き出せる便利なツールです。

しかし、本番環境のシステム開発においては、「パフォーマンス」「保守性」「セキュリティ」の3つの観点から、列名を明示的に指定することが鉄則とされています。

初心者のうちはアスタリスクを多用してしまいがちですが、実務レベルのSQLを書くためには、面倒でも必要なカラムを1つずつ列挙する癖をつけましょう。

一方で、デバッグ作業やEXISTS句、最新のEXCEPT構文など、アスタリスクが有効に機能する場面も正しく理解しておくことが大切です。

適切な場面で適切な書き方を選択できることが、プロフェッショナルなエンジニアへの近道となります。

日々のコーディングの中で、今書いている「*」が本当に最適なのか、一度立ち止まって考えてみてください。