SQLのSELECTとWHERE入門|抽出の基本から条件指定・よく使うパターンまで
この記事でできるようになること(SELECTで抽出→WHEREで条件指定)
この記事は、SQLで「必要なデータだけを取り出す」ための最初の一歩として、SELECT文とWHERE句をまとめて整理する。
この記事では「SQLの書き方」だけでなく、「どう考えて条件を組み立てるか」までを一緒に扱う。
SQLは暗記よりも「読み方の型」を持つ方が伸びるので、読み方のコツも途中で織り交ぜる。
この記事のゴール(何が分かるか)
読み終えると、SELECTで列を選び、WHEREで行を絞り、よく使う条件パターンを自分で組み立てられるようになる。
さらに、条件が増えたときにANDとORをどう読めばよいかを、括弧の付け方まで含めて説明する。
「結果が合わないときに、どこを疑うか」というチェック順も覚えられるようにする。
先に結論:SELECTとWHEREはセットで覚える
抽出はSELECT、条件はWHEREという役割分担を押さえると、SQLの学習が一気に進めやすくなる。
SELECTだけを覚えても「全部取れて終わり」になりやすいので、最初からWHEREまでを1セットで練習する。
慣れてきたら「欲しい結果を日本語で言う→SQLに落とす」を繰り返すと、応用にも強くなる。
SQLの前提:テーブルとカラムを最小限で整理する
ここでは例を固定し、同じテーブル名とカラム名で読み方を統一して混乱を減らす。
例が毎回変わると、SQLそのものではなく「どのテーブルの話か」でつまずきやすい。
特に初心者は、条件の意味よりも固有名詞に引っ張られやすいので、まずはモデルを固定する。
例で使うテーブル(users / orders)の想定
以降の例では、ユーザー情報のusersと、注文情報のordersがある前提で説明する。
現場ではテーブル名やカラム名は環境ごとに異なるが、考え方は同じなので置き換えて読めばよい。
「ユーザーを絞る」「注文を絞る」という2種類の例があると、WHEREの発想が広がりやすい。
| テーブル | 主なカラム | 意味 |
|---|---|---|
| users | id, name, age, prefecture, created_at | ユーザーの基本情報 |
| orders | id, user_id, amount, status, ordered_at | 注文の情報 |
「行」と「列」を混同しないための見方
SELECTは「列を選ぶ」操作で、WHEREは「行を減らす」操作だと考えると整理しやすい。
「列=項目」「行=1件のデータ」と頭の中で置き換えると、SQLの読み方が安定する。
迷ったら、SELECTの後ろに書いているのが列名で、WHEREの右側に書いているのが値だと意識する。
SELECT文の基本(抽出)
まずはSELECTの最小構文から入り、列の指定と表示名の調整までを確認する。
結果の見やすさは「必要な列を必要な順で出す」だけでも大きく変わる。
「欲しい列だけを出す」という癖が付くと、WHEREの条件も書きやすくなる。
最小構文:SELECT … FROM …
SQLの基本形は、どの列を取り出すか(SELECT)と、どのテーブルから取るか(FROM)で決まる。
SQLは上から順に読めばよいとは限らないので、まずは役割で区切って読む癖を付ける。
最初は「SELECTで何を出すか」「FROMでどこから出すか」だけを確認できれば十分だ。
“`sql
SELECT カラム名
FROM テーブル名;
“`
「*」で全部取るときの注意点
`SELECT *` は手軽だが、列が増えると読みづらくなり、必要以上にデータを扱うことにもつながる。
学習の初期は便利だが、慣れてきたら「必要な列だけ」を選ぶ方針に切り替えるとよい。
本番環境での大量データでは、`*` が性能や転送量のムダにつながることもある。
“`sql
SELECT *
FROM users;
“`
カラムを指定して抽出する基本
必要な列だけを指定すると、結果が読みやすくなり、何を見たいのかも明確になる。
「いま確認したいのは何か」を1回言語化してから列を選ぶと、クエリが短くなる。
学習中は、まずidとnameのように「識別しやすい列」を入れて結果を確認するのが安心だ。
“`sql
SELECT id, name
FROM users;
“`
複数カラムの並べ方と読み方
カラムはカンマで区切り、結果の左から順に「見る順番」だと思うと理解しやすい。
まず識別子(id)を左に置き、次に表示名(name)を置くと、結果の目視確認が楽になる。
列が多いときは、後で使う列ほど右側に寄せると、目の負担が減る。
“`sql
SELECT id, name, age, prefecture
FROM users;
“`
ASで別名を付ける(表示用の名前を変える)
ASは、結果の列名を読みやすい表示名に変えるための機能として使うことが多い。
表示用の名前をそろえると、集計やレポート用に結果を使うときに扱いやすい。
別名は「何を表す列か」が伝わる名前にしておくと、後から見返したときに迷いにくい。
“`sql
SELECT name AS user_name, prefecture AS pref
FROM users;
“`
SELECTの結果を確認するコツ
SQLの学習では、まず少ない行数で試し、結果を見ながら書き直す方が身に付く。
WHEREを付ける前の段階でも、列の指定が意図どおりかを先に確認しておく。
エラーが出たら、まずはSELECTとFROMだけで動く形に戻してから、要素を足していく。
WHERE句の基本(条件指定)
WHEREは「どの行を残すか」を決めるための句で、SELECTと組み合わせて使う場面が非常に多い。
条件を付けると結果が一気に絞れるので、最初に覚える価値が高い。
WHEREは「対象を限定する言葉」をSQLへ置き換える作業なので、慣れるほど書くのが楽になる。
WHEREの役割(必要な行だけに絞る)
WHEREを付けると、条件に合う行だけが結果に残るので、必要なデータへ素早くたどり着ける。
条件は「人間の言葉」から「SQLの形」へ置き換える作業だと考えると組み立てやすい。
条件が曖昧なときは、まず「どの列で絞るか」を決めると一気に書けるようになる。
“`sql
SELECT id, name, age
FROM users
WHERE age >= 20;
“`
比較演算子(=, <, >, <=, >=, <>, !=)の基本
比較演算子は「等しい」「大きい」「小さい」「等しくない」を表し、条件指定の土台になる。
- `=`:等しい。
- `<`:より小さい。
- `>`:より大きい。
- `<=`:以下。
- `>=`:以上。
- `<>` または `!=`:等しくない。
同じ意味の書き方が複数ある場合は、チームの規約に合わせて統一すると読みやすい。
境界条件はミスが出やすいので、`>=` と `>` を使い分ける理由を意識して書く。
“`sql
SELECT id, name
FROM users
WHERE prefecture = ‘Tokyo’;
“`
文字列条件の基本(引用符の考え方はDBで差がある点に注意)
文字列の書き方や大文字小文字の扱いはDBで差が出るので、結果が合わないときはまずそこを疑う。
文字列を比較しているつもりが、実際は空白や全角半角の差で一致しないこともある。
検索対象の文字がユーザー入力由来の場合は、前後の空白を疑うだけでも発見が早い。
“`sql
SELECT id, name
FROM users
WHERE name = ‘Sato’;
“`
数値条件の基本(範囲指定の発想)
数値は大小比較がしやすいので、まずは「以上」「以下」「範囲」を書けるようにする。
境界を含めるかどうかを、`>=` と `>` の違いで意識するとミスが減る。
範囲が連続するならBETWEEN、片側だけなら`>=`や`<`と覚えると迷いにくい。
“`sql
SELECT id, name, age
FROM users
WHERE age < 18;
“`
WHEREを書くときの基本手順
最初は「列名」「演算子」「値」の3つを並べるだけでよい。
複雑な条件に見えても、1つずつ条件に分解してから並べると整理しやすい。
迷ったら、条件を日本語で1文にしてから、列と値に分解して書く。
AND / ORで条件を組み合わせる
条件が増えると読み間違いが起きやすいので、ANDとORの基本と括弧をセットで覚える。
「どこからどこまでが1つの塊か」を決めるのが、括弧の役割だと考える。
複数条件は、最終的に「どういう人を取りたいか」を言葉で言えるかが大事になる。
ANDの考え方(両方満たす)
ANDは、左右の条件をどちらも満たす行だけを残すときに使う。
ANDが増えるほど結果は絞られるので、まずはANDから練習すると分かりやすい。
ANDは「絞り込みの追加」と考えると自然で、条件の増え方もイメージしやすい。
“`sql
SELECT id, name, age
FROM users
WHERE prefecture = ‘Tokyo’
AND age >= 20;
“`
ORの考え方(どちらか満たす)
ORは、左右の条件のどちらかを満たす行を残すときに使う。
ORが増えるほど結果は広がるので、意図せず件数が増えたときはORを疑う。
ORは「候補を増やす」と考えると理解しやすいが、混ざるときは必ず括弧で守る。
“`sql
SELECT id, name, prefecture
FROM users
WHERE prefecture = ‘Tokyo’
OR prefecture = ‘Kanagawa’;
“`
優先順位と括弧(読み間違いを防ぐ)
ANDとORが混ざるときは、意図を明確にするために括弧でグループ化する。
括弧が無いと、読み手が「どちらを先に評価するのか」で迷い、バグの原因にもなる。
迷ったら必ず括弧を付けて、読む人が同じ解釈になる形にしておく。
“`sql
SELECT id, name, age, prefecture
FROM users
WHERE (prefecture = ‘Tokyo’ OR prefecture = ‘Kanagawa’)
AND age >= 20;
“`
条件を増やすときの確認方法
条件を追加したら、件数がどう変わったかを必ず確認して、増減の理由を説明できるようにする。
期待と違うときは、直近で追加した条件だけを一旦外して差分を見ると原因に近づきやすい。
件数だけでなく、サンプル行を数件見て「どの条件で引っかかったか」を確認する。
よく使うWHEREのパターン集
ここからは頻出の書き方をまとめて確認し、実務でも使える形に整える。
パターンを覚えると、条件を文章からSQLへ変換するスピードが上がる。
同じ意味の条件でも、読みやすい書き方を選べるようになるのが狙いだ。
INで「いくつかの候補」に一致させる
候補が複数あるときはORを連ねるよりINでまとめると読みやすい。
候補が増えたときに1行を足すだけで済むので、修正にも強い。
候補の数が多いときは、値の管理方法も含めて考えると運用が楽になる。
“`sql
SELECT id, name, prefecture
FROM users
WHERE prefecture IN (‘Tokyo’, ‘Kanagawa’, ‘Chiba’);
“`
BETWEENで範囲を指定する(境界を含むかの確認)
BETWEENは範囲指定が簡単だが、境界を含むかどうかの解釈はまず確認する。
境界を含めたくない場合は、`>=` と `<` を組み合わせた方が意図が明確になることもある。
期間条件など「終端を含めない」方針は、読みやすさだけでなく事故防止にもつながる。
“`sql
SELECT id, name, age
FROM users
WHERE age BETWEEN 20 AND 29;
“`
LIKEで部分一致(ワイルドカードの基本)
LIKEは部分一致に便利だが、ワイルドカードの位置で意味が変わるので最初は例で覚える。
- `%abc%`:途中にabcを含む。
- `abc%`:abcで始まる。
- `%abc`:abcで終わる。
検索したい語が短いほど、想定以上に件数が増えやすい点も意識する。
まずは前方一致(`abc%`)で試し、必要なときだけ範囲を広げると確認がしやすい。
“`sql
SELECT id, name
FROM users
WHERE name LIKE ‘Sa%’;
“`
NULLの扱い(IS NULL / IS NOT NULL)
NULLは「値がない」状態なので、`=` ではなくIS NULLで判定する。
NULLが混ざると、条件式の結果が思ったとおりにならないことがあるので最初に確認する。
NULLは「空文字」や「0」と違うので、データの意味としてどう扱うかも意識する。
“`sql
SELECT id, name
FROM users
WHERE prefecture IS NULL;
“`
日付・時刻の条件(DB差があるので考え方を押さえる)
日付の型や比較の書き方はDBで差が出るので、まずは「期間で絞る」考え方を覚える。
日付は境界をそろえて書くと、月末やうるう年の扱いで混乱しにくい。
「開始は含める」「終了は含めない」の形にしておくと、月替わりでもズレにくい。
“`sql
SELECT id, name, created_at
FROM users
WHERE created_at >= ‘2025-01-01’
AND created_at < ‘2026-01-01’;
“`
statusのような状態カラムで絞る
実務では「statusが何か」で絞るケースが多いので、固定値の条件もよく出てくる。
値の一覧がある場合は、まずは候補を確認してから条件を書くと安全になる。
状態が複数ある場合は、INでまとめるか、優先順位を決めて条件を分ける。
具体例で覚える:SELECT + WHEREの定番クエリ
同じテーブルを使って段階的に条件を増やすと、WHEREの組み立てが身に付きやすい。
いきなり難しい条件を作るより、単純なクエリを何度も書いて「形」を覚えるのが近道になる。
結果が合っているかを自分で説明できるようになると、WHEREの理解が一段深くなる。
条件1つの基本例(まずは単純に絞る)
最初は「都道府県で絞る」「年齢で絞る」のように、条件を1つに固定して確認する。
同じ列で値だけ変えて試すと、条件式の意味が理解しやすくなる。
まずは「当たるはずの人が当たるか」を確認し、次に「当たらないはずの人が外れるか」を見る。
“`sql
SELECT id, name
FROM users
WHERE prefecture = ‘Tokyo’;
“`
条件を2つ以上に増やす例(AND/ORと括弧)
次に条件を増やすときは、どこでグループ化したいのかを括弧で明確にする。
最初は括弧を多めに付けて、意図を見える形にしておくと読み間違いが減る。
条件が多いほど、括弧は「説明書」だと思って遠慮なく付ける。
“`sql
SELECT id, name, age, prefecture
FROM users
WHERE (prefecture = ‘Tokyo’ OR prefecture = ‘Kanagawa’)
AND age BETWEEN 20 AND 39;
“`
並び替えや重複除去に繋げる例(次の記事へ自然に接続)
抽出できたら、次は並び替えや重複除去で結果を見やすくする流れになる。
結果の見え方が整うと、WHEREの条件が合っているかも判断しやすくなる。
条件確認のためにもORDER BYは役に立つので、早い段階で触れておくと便利だ。
同じSELECTの流れでDISTINCTとORDER BYに進むなら、SQL の 基本 DISTINCT / ORDER BY でコントロール! に繋げると理解が続きやすい。
まずはLIMITで小さく見るという考え方
大きなテーブルを想定する場合は、最初は少ない件数で結果を確認するのが安全だ。
LIMITの有無や書き方はDBで差があるので、利用しているDBの仕様に合わせて確認する。
結果の上位だけを見る癖が付くと、試行錯誤の回転数が上がって理解が早くなる。
安全運用:WHEREは更新系にも直結する(事故を防ぐ)
WHEREは参照だけでなく更新でも使うため、まずは「意図どおりの件数か」を確認する癖を付ける。
更新系はミスの影響が大きいので、確認の手順を文章として覚えると実行ミスが減る。
安全運用はテクニックというより習慣なので、毎回同じ手順で確認できる形にする。
UPDATE/DELETEの前に同じ条件でSELECTして件数確認する
更新や削除を実行する前に、同じWHEREでSELECTして対象件数を確かめると事故が減る。
対象が多い場合ほど「本当にその条件でよいか」を結果のサンプルで確認してから実行する。
更新の前に「対象の特徴」を数件見ておくと、誤更新に早く気づける。
“`sql
— まず対象を確認する
SELECT id, name, status
FROM orders
WHERE status = ‘pending’;
— 確認後に更新する(例)
UPDATE orders
SET status = ‘processing’
WHERE status = ‘pending’;
“`
影響範囲が広いときの確認手順(まず小さく試す)
条件が不安なときは、絞り込みを強めて小さく確認しながら段階的に広げる。
例えば「特定のユーザーだけ」や「期間を短くする」など、確認しやすい形に変えて見る。
最初は安全側に倒して条件を厳しくし、確認が取れたら少しずつ広げる。
更新の文脈でWHEREの考え方を復習したい場合は、SQL の 基本 UPDATE で既存データの更新! を合わせて読むと整理しやすい。
変更前後を比較する視点
更新の前に対象行をSELECTし、更新後にも同じ条件でSELECTして差分を見る。
この手順があるだけで、「思ったより広く更新した」事故に気づきやすくなる。
差分を見るときは、更新対象のキー(idなど)を必ず出しておくと比較がしやすい。
つまずきポイントと対処
WHEREが思ったとおりに動かないときは、原因探しよりもチェック手順を固定した方が早い。
順番に確認すればよいポイントを決めておくと、慣れていない人でも再現性が高くなる。
「直近で何を変えたか」を追えるようにすると、SQLの修正が怖くなくなる。
条件が効かないとき(NULL・LIKE・型の違いで起きやすい)
NULLの比較やLIKEのワイルドカード、文字列と数値の型違いを順番に確認する。
一致しているはずなのに引っかからない場合は、空白や記号の混入も疑う。
まずは比較している列の実データを数件出して、想定と違っていないかを見る。
期待より件数が多い/少ないとき(AND/ORと括弧を見直す)
ANDとORが混ざるときは、括弧で意図した順に評価されているかを確認する。
一旦括弧を増やして書き直し、同じ意味でも読みやすい形に整えると再発しにくい。
件数が多すぎるときはOR、少なすぎるときはANDや境界条件を疑うと切り分けが速い。
条件が増えて読みにくいとき(段階的に足して確認する)
最初は条件を1つだけにして動作確認し、合ってから条件を1つずつ追加する。
追加した条件ごとに件数がどう変わったかをメモすると、後で見直しやすい。
条件を追加するときは、1回に1つだけ足すと、何が原因かが分かりやすい。
まずSELECT文だけを動かしてからWHEREを付ける
いきなりWHEREまで書かず、まずはSELECTとFROMだけで結果が取れることを確認する。
その後にWHEREを付けると、エラーの切り分けが簡単になる。
テーブル名や列名の間違いは、この段階で潰せるので遠回りに見えて実は早い。
よくある質問(FAQ)
最後に、SELECTとWHEREで出やすい疑問を短く整理する。
迷いやすいポイントを先に知っておくと、学習のつまずきが減る。
質問は「何を知らないか」を明確にしてくれるので、疑問が出たらメモしておくと良い。
WHEREとHAVINGの違いは何?
WHEREは行を絞り、HAVINGはGROUP BYでまとめた後の結果を絞ると覚える。
迷ったら「集計前はWHERE、集計後はHAVING」と言葉で言えるかを確認する。
HAVINGを使う場面ではGROUP BYが前提になるので、まずはWHEREに慣れてからで十分だ。
文字列の大文字小文字は区別される?
区別の有無はDBや設定で変わるので、同じSQLでも環境差が出る点に注意する。
特に移行作業やローカルと本番でDBが違う場合は、結果差が出やすい。
差が出たら、まずは照合順序や比較ルールの設定を確認する。
LIKEが遅いと言われるのはなぜ?
先頭が`%`のLIKEは検索範囲が広くなりやすく、件数が増えるほど重くなることがある。
検索を多用する場合は、前方一致に寄せるなどの工夫が必要になることがある。
まずは件数がどれくらい増えるかを確認し、必要なら検索方法の見直しを検討する。
「抽出→集計」へ進むときに次に覚えるものは?
まずはORDER BYやDISTINCTで結果を整え、その次に集計関数とGROUP BYへ進むとスムーズになる。
「抽出」「整形」「集計」の順で覚えると、何をしているかが見失いにくい。
学習中は1つの段階を短いクエリで試し、結果が読める状態で次へ進む。
WHEREに書いた条件が意図どおりか不安なときは?
同じ条件でまず件数を確認し、次にサンプル行を見て納得できるかをチェックする。
条件が複雑なときほど、確認用のSELECTが役に立つ。
確認用のSELECTは残しておくと、後で条件を変更するときの安全柵にもなる。
次に学ぶロードマップ(シリーズ内の位置づけ)
学習順を決めておくと、同じテーマの行き来で迷いにくくなる。
「今は何を覚える段階か」を固定すると、記事が増えても迷子になりにくい。
ロードマップは「次に何をやるか」を迷わないための地図として使う。
抽出結果の整形(DISTINCT / ORDER BY)
抽出した結果を見やすくする段階として、DISTINCTとORDER BYを先に押さえる。
整形を先に覚えると、WHEREの結果が正しいかを目で追いやすくなる。
実務では結果を読む時間が長いので、整形は早めに覚えるほど得をする。
集計(AVG/MAX/MIN/SUM/COUNT)
数を数えたり合計したりする集計は、WHEREで必要な行を絞った後に使うと理解しやすい。
集計の前に条件を付けられると、結果の意味がはっきりする。
集計は「何を数えるか」を決める作業でもあるので、SELECTの列選びが役に立つ。
グループ化(GROUP BY / HAVING)
グループ化は「まとめてから考える」操作なので、WHEREの次の段階として学ぶと整理しやすい。
WHEREとHAVINGの違いが分かると、集計クエリの読み方が安定する。
まずはGROUP BYでまとめる感覚を掴み、最後にHAVINGで絞る流れを覚える。
更新(INSERT / UPDATE)とWHEREの関係
更新ではWHEREが事故防止の要になるので、SELECTで確認する癖とセットで覚える。
「更新したい行だけに当たっているか」を確認するのが、WHEREの実務的な使い方になる。
更新系こそ確認用SELECTが活きるので、WHEREの書き方がそのまま安全性に直結する。
まとめ(SELECT/WHEREの最短復習)
最後に、今日の要点を短く再確認して終える。
忘れやすい部分を短い文章で復習すると、次にSQLを書くときに迷いにくい。
復習は「読む」より「自分で1本クエリを書く」方が効果が出やすい。
今日の要点3つ
SELECTは列を選び、FROMはテーブルを決め、WHEREは行を絞る。
条件が増えたら、ANDとORの優先順位を括弧で固定する。
NULLはIS NULLで判定し、LIKEや日付条件はDB差が出る前提で確認する。
まず試すべき練習ステップ
同じテーブルで条件を1つずつ増やし、結果件数が変わる理由を言葉にして確認する。
最初は「条件1つ→条件2つ→括弧を使う」の順で難易度を上げると無理がない。
条件が増えたら、1つ追加するたびに件数とサンプル行を見て、意図どおりかを確かめる。
SQL基礎シリーズの全体像を先に掴むなら、SQL を マスター してみる。〖分類整理〗 から読むと迷いにくい。