sql orの使い方完全ガイド：優先順位・IN句・NULL罠まで解説 -

この記事ではSQLのWHERE句で使うAND（全条件を満たす）とOR（いずれかを満たす）の違い、構文例、優先順位（ANDが先）と括弧の使い方を解説します。複数条件で意図しない抽出結果になる原因を理解し、正しい検索条件を組み立てられます。

1 SQLのOR演算子とは（「または」を表す条件式）
2 OR条件を複数指定する実践パターン
3 ANDとORを併用する際の優先順位と括弧（バグ防止）
4 SQL ServerのOR関連トピック（OR演算子／CREATE OR ALTER）
5 OR条件で意図しない結果を防ぐためのチェックポイント
6 まとめ（SQLのORを正しく使う要点）

SQLのOR演算子とは（「または」を表す条件式）

ORの基本的な役割と使いどころ

SQLのOR演算子は、WHERE句などで「条件A または 条件B」を表すための論理演算子です。複数の候補のうち、どれか1つでも条件を満たせば行を抽出できるため、検索条件の幅を広げたいときに活躍します。

たとえば、次のような場面で「sql or」を使うと、意図したデータを自然に取り出せます。

顧客区分が「法人」または「個人事業主」のデータを抽出したい
都道府県が「東京都」または「神奈川県」のユーザーを抽出したい
ステータスが「未対応」または「対応中」の案件だけ見たい

このように、「いずれかに該当する」条件をまとめて指定できるのがORの基本的な役割です。

ANDとの違いを整理する

ORを正しく使うには、似た役割のANDとの違いを押さえることが重要です。両者はどちらも条件を組み合わせますが、一致の判定基準が根本的に異なります。

AND（かつ）の意味と挙動

ANDは「条件A かつ条件B」を意味し、両方の条件を同時に満たす行だけが抽出されます。条件を追加するほど絞り込みが強くなり、結果件数は同じか少なくなるのが一般的です。

イメージとしては、フィルターを重ねていく感覚です。「部署が営業部」かつ「役職がマネージャー」といったように、条件を満たす対象を狭めたいときに使います。

OR（または）の意味と挙動

ORは「条件A または 条件B」を意味し、どちらか一方でも条件を満たす行が抽出されます。条件を追加するほど対象が増えるため、結果件数は同じか多くなるのが一般的です。

イメージとしては、複数の入口（条件）を用意して、そこに当てはまるものをまとめて拾う感覚です。「部署が営業部」または「部署がマーケティング部」のように、候補を広く取りたいときに適しています。

ORの基本構文（WHERE句での書き方）

SQLのOR演算子は、主にWHERE句の条件式として次の形で記述します。条件を2つ以上つなぐときに「OR」を挟むのが基本です。

SELECT 列名
FROM テーブル名
WHERE 条件A OR 条件B;

条件Aと条件Bには、比較演算子（=、<>、>、< など）や、文字列・数値・日付の比較式が入ります。なお、複数のORを連結して書くことも可能です。

SELECT 列名
FROM テーブル名
WHERE 条件A OR 条件B OR 条件C;

この構文が「sql or」の最も基本的な形で、検索条件の候補を並列に並べるときの土台になります。

具体例で理解するOR条件の動き

OR条件は「どれかに一致すればOK」という性質上、結果に含まれる行の範囲を直感的に掴むことが大切です。ここでは、よくある例でORの動きを確認します。

たとえば、社員テーブル（employees）があり、部署（department）が「Sales」または「Marketing」の社員を取得したいとします。

SELECT *
FROM employees
WHERE department = 'Sales' OR department = 'Marketing';

このSQLでは、department列がSalesの行も、Marketingの行も抽出対象になります。つまり、次のいずれかに該当すれば結果に含まれます。

department = ‘Sales’ を満たす
department = ‘Marketing’ を満たす

もう1つ、数値条件の例です。テスト結果テーブル（scores）から、点数（score）が「90以上」または「50未満」の行を抽出するケースを考えます。

SELECT *
FROM scores
WHERE score >= 90 OR score < 50;

この場合、高得点のグループと低得点のグループが同時に抽出されます。ORは「間の範囲」ではなく「両端の条件を満たすもの」を拾うため、scoreが50以上90未満の行は抽出されません。このように、ORは条件式の意味をそのまま反映するので、「どの行が拾われ、どの行が落ちるか」を条件ごとに確認すると理解しやすくなります。

OR条件を複数指定する実践パターン

SQLのORは「どれか1つでも条件に合えばOK」という検索に便利ですが、条件が増えるほどWHERE句が長くなり、読みづらさやメンテナンス性の低下につながります。ここでは、sql orで複数条件を扱うときに現場でよく使われる書き方を、代表例→IN句→DB製品ごとの注意点の順で整理します。

代表的な記述例（複数の候補に一致させる）

最も素直な書き方は、同じ列に対して候補値をORでつなぐパターンです。たとえば「部門が営業またはマーケティングの行だけ欲しい」といったケースで使います。

SELECT
  employee_id, name, department
FROM employees
WHERE department = 'Sales'
   OR department = 'Marketing';

列が異なる条件でもORで結べます。例えば「地域が東京、または売上が一定以上」といった“別軸のどちらか”で拾う検索もORの典型です。

SELECT
  order_id, region, amount
FROM orders
WHERE region = 'Tokyo'
   OR amount >= 100000;

候補が3つ以上になるとORの羅列が増えて見通しが悪くなるため、次のIN句の利用を検討するのが実務的です。

IN句でORの羅列を簡潔に書く方法

同じ列に対する「AまたはBまたはC…」は、IN句を使うと短く、読みやすく書けます。結果として条件追加・削除もしやすくなり、sql orを多用したWHERE句の肥大化を防げます。

IN句の概要と基本形

IN句は「指定した集合のいずれかに一致する」条件を表します。ORでの同値比較をまとめる用途で最も使われます。

-- ORの羅列
SELECT *
FROM employees
WHERE department = 'Sales'
   OR department = 'Marketing'
   OR department = 'HR';

-- IN句で簡潔に
SELECT *
FROM employees
WHERE department IN ('Sales', 'Marketing', 'HR');

候補が多いほどIN句のメリットは大きく、SQL全体の可読性やレビュー効率も上がります。値の並びは意味を持たないため、チームで「アルファベット順にする」「業務順にする」などルールを決めると保守が楽になります。

NOT IN句の概要と使い分け

NOT IN句は「指定した集合のいずれにも一致しない」条件です。OR条件の否定をまとめるときに役立ちます。

SELECT *
FROM employees
WHERE department NOT IN ('Temporary', 'Outsource');

使い分けとしては、次のように考えると整理しやすいです。

含めたい候補が列挙できる：IN (...)
除外したい候補が列挙できる：NOT IN (...)

また、NOT INを使うときは、比較対象の列や候補側にNULLが絡むと挙動が期待とズレやすいため、データ設計（NULLを許容しているか）を踏まえて慎重に適用します。

サブクエリと組み合わせたIN／NOT IN

IN／NOT INは、値リストだけでなくサブクエリ結果（別SELECTの結果集合）に対しても使えます。固定の候補ではなく「条件を満たすユーザー一覧」「対象商品の一覧」のように、動的に集合を作って判定する場面で便利です。

-- ある条件を満たす顧客の注文だけを取得
SELECT
  o.order_id, o.customer_id, o.amount
FROM orders o
WHERE o.customer_id IN (
  SELECT c.customer_id
  FROM customers c
  WHERE c.status = 'ACTIVE'
);

除外したい集合をサブクエリで作る場合はNOT INを使います。

-- ブラックリスト顧客の注文を除外
SELECT
  o.order_id, o.customer_id, o.amount
FROM orders o
WHERE o.customer_id NOT IN (
  SELECT b.customer_id
  FROM blacklist b
);

サブクエリの戻り値は、基本的に「比較する列と同じ型・同じ意味の値」になるように揃えるのが重要です。型が揃っていないと暗黙変換が発生し、意図しない比較やエラーにつながることがあります。

データベース製品ごとの注意点（方言差の確認）

ORやIN自体はSQLとして広く共通ですが、実務では「インデックス利用のされ方」「最適化の傾向」「式の書き方の許容範囲」などが製品ごとに異なることがあります。ここでは代表的なDBで、sql orを複数条件で書くときに押さえたい“確認観点”をまとめます。

OracleでのORの扱いのポイント

OracleではOR条件が絡むと、統計情報や条件の組み合わせによって実行計画が変わりやすいことがあります。特に同一列に対する候補一致はIN句にまとめることで意図が明確になり、チューニング時の議論もしやすくなります。

同値比較のOR羅列は、可能ならIN (...)にまとめて可読性を上げる
サブクエリIN／NOT INを使う場合、戻り値の型・桁・文字種（全角半角など）が揃っているかを確認する

SQL ServerでのORの扱いのポイント

SQL Serverでは、ORを含む条件は実行計画の選択に影響しやすく、同じ意味でも書き方の違いで性能差が出ることがあります。候補列挙が中心ならIN句化が読みやすく、保守もしやすい選択です。

同一列の候補一致はINにまとめるとWHERE句が短くなる
サブクエリの結果が大きい場合、想定より重くなることがあるため、対象件数の見積もりを行う

MySQLでのORの扱いのポイント

MySQLでもOR／INは一般的に利用できますが、列の型や照合順序（collation）によって比較結果が変わることがあります。特に文字列比較では、同じ見た目でも一致判定が揺れるケースがあるため、候補値の管理（マスタ化など）と合わせて検討すると安全です。

同一列の複数候補はINにまとめ、候補値の管理をしやすくする
サブクエリIN／NOT INは、比較列の型・照合順序の一致を意識する

PostgreSQLでのORの扱いのポイント

PostgreSQLではORやINは標準的に扱えます。複数候補の一致はIN句で簡潔に書け、SQLの意図が明確になります。サブクエリと組み合わせる際も、返す列が1列であること、型が一致していることを基本として確認します。

ORの羅列はINへ置き換えると読みやすく、条件追加もしやすい
サブクエリを使う場合、比較対象の列型を揃えて暗黙キャストを避ける

ANDとORを併用する際の優先順位と括弧（バグ防止）

SQLのWHERE句でANDとORを組み合わせると、見た目は直感的でも「思った条件になっていない」事故が起きやすくなります。特にsql orのようにOR条件が絡む検索は、優先順位の誤解がそのまま抽出ミス（＝バグ）につながります。このセクションでは、論理演算子の評価順序と、括弧で意図を固定する実務的な書き方、そしてありがちな間違いの修正方法を整理します。

論理演算子の評価順序（ANDが先、ORが後）

SQLでは一般に、論理演算子の評価順序はANDが先、ORが後です。つまり、括弧がない場合は「ORで区切った左右」ではなく、ANDが優先的にひとまとまりとして評価されます。

イメージとしては、次のように解釈されます。

-- 見た目
A OR B AND C

-- 実際の評価（ANDが先）
A OR (B AND C)

このルールを知らないままsql or条件を増やすと、例えば「AまたはB、さらにCも満たす」と書いたつもりが、「Aは無条件でOK、Bの場合だけCが必要」になってしまうなど、要件と結果がズレやすくなります。

括弧で意図した条件に固定する書き方

バグ防止の基本は、ORを含む条件は括弧でグルーピングして意図を固定することです。特に次のような意図は、括弧の有無で結果が大きく変わります。

「（AまたはB）かつC」
「Aまたは（BかつC）」

たとえば「カテゴリがAまたはBで、かつ公開中のデータだけ」を取りたい場合、OR部分を括弧で囲ってからANDをつなげます。

SELECT *
FROM articles
WHERE (category = 'A' OR category = 'B')
  AND status = 'published';

このように書くことで、DBが持つ優先順位（ANDが先）に依存せず、読み手にも「ORの塊」と「追加条件」が明確に伝わります。結果として、レビュー時の見落としや後日の改修時に起きる条件崩れも減らせます。

実務的なコツとしては、次の運用が効果的です。

ORが1つでも出たら括弧を付ける（慣習として徹底）
複雑な条件ほど1行1条件にして括弧の対応を見やすくする
括弧の単位を「要件の日本語」に合わせる（例：「対象者条件」「期間条件」などで塊を作る）

ありがちな間違い例と正しい修正例

ここでは、ANDとORの優先順位によって起きがちなミスを、具体的なSQLで示します。ポイントは「括弧がないとANDが先に評価される」ことです。

間違い例：ORのつもりが、片側だけにAND条件がかかってしまう

-- 意図：部門が営業またはマーケで、かつ有効ユーザーだけ
-- 実際：営業は無条件でOK、マーケだけ有効が必要（ANDが先のため）
SELECT *
FROM users
WHERE department = 'sales'
   OR department = 'marketing'
  AND is_active = 1;

上記はSQLの評価順序により、次と同じ意味になります。

WHERE department = 'sales'
   OR (department = 'marketing' AND is_active = 1)

正しい修正例：OR条件を括弧でまとめてからANDを適用する

SELECT *
FROM users
WHERE (department = 'sales' OR department = 'marketing')
  AND is_active = 1;

この修正により、「sales/marketingのどちらであっても、必ずis_active = 1が必要」という意図がSQL上も固定されます。

別のありがちパターン：ORを足したら絞り込みが急に緩くなった

-- 意図：管理者、または（一般ユーザーで本人のデータ）だけ
-- 括弧がないと解釈がブレやすく、改修時に事故りやすい
SELECT *
FROM records
WHERE role = 'admin'
   OR role = 'user'
  AND user_id = :login_user_id;

この場合もANDが先のため、次の意味になります。

WHERE role = 'admin'
   OR (role = 'user' AND user_id = :login_user_id)

もし意図が「（管理者または一般ユーザー）で、かつ本人のデータ」だったなら、次のように括弧位置を変える必要があります。

SELECT *
FROM records
WHERE (role = 'admin' OR role = 'user')
  AND user_id = :login_user_id;

このように、sql or条件は「どの条件同士を同じ塊として評価したいか」を括弧で明示しないと、要件と結果が食い違いやすくなります。AND/ORを併用する場面では、優先順位を暗記するより、括弧で固定することをルール化するのが最も安全です。

SQL ServerのOR関連トピック（OR演算子／CREATE OR ALTER）

SQL Serverでは、一般的なSQLのOR条件（論理演算子）に加えて、Transact-SQL（T-SQL）としての仕様上の注意点や、DDLで便利な「CREATE OR ALTER」構文が存在します。このセクションでは「sql or」という観点で、SQL Serverに特有のポイントを整理します。

OR（Transact-SQL）の構文要点

SQL ServerのORは、WHERE句などで複数条件のどちらか（またはいずれか）が成り立つ場合に真（TRUE）として扱う論理演算子です。T-SQLでは、演算子の優先順位やNULLを含むときの挙動など、結果が想定とズレないように構文と注意点を押さえることが重要です。

構文（Syntax）

ORの基本構文は次のとおりです。SQL ServerのT-SQLでも標準SQLと同様に、条件式同士をORで連結します。

-- 一般形
<condition> OR <condition>

-- WHERE句での典型
SELECT ...
FROM ...
WHERE 条件A OR 条件B;

ORはWHERE句だけでなく、JOIN条件やHAVING句、CASE式の条件分岐など、真偽値を扱う場所で利用できます（ただし「成り立つ／成り立たない」を評価できる式である必要があります）。

引数（Arguments）

ORの「引数」は、左右に置かれる2つの条件式（述語）です。SQL Serverでは、以下のような比較・判定結果（真偽）を返す式をORでつなぎます。

比較演算：=、<>、>、<、>=、<=
範囲判定：BETWEEN
集合判定：IN
存在判定：EXISTS
NULL判定：IS NULL / IS NOT NULL
文字列パターン：LIKE

重要なのは、ORで接続される各条件が「論理式として評価できること」です。数値や文字列そのものを直接ORの左右に置くのではなく、比較や判定の形にする必要があります。

戻り値・結果の扱い（結果の種類／結果値）

OR自体は「論理演算子」であり、式全体は真偽として評価されます。ただし、SQL Server（およびSQL一般）の検索条件は三値論理（TRUE / FALSE / UNKNOWN）で動作します。NULLが絡むとUNKNOWNになり得る点が、sql or での結果解釈に直結します。

左条件	右条件	左 OR 右の結果
TRUE	TRUE	TRUE
TRUE	FALSE	TRUE
FALSE	TRUE	TRUE
FALSE	FALSE	FALSE
UNKNOWN	TRUE	TRUE
UNKNOWN	FALSE	UNKNOWN
UNKNOWN	UNKNOWN	UNKNOWN

SQL ServerのWHERE句では、最終結果がTRUEとなる行のみが返ります。したがって、OR条件の結果がUNKNOWNの行は返りません（TRUE扱いにはならない）。この仕様は、NULLを含むデータを扱うときに「思ったより件数が出ない／出過ぎる」といったズレの原因になります。

注意事項（Remarks）

T-SQLでORを使う際の注意点を、SQL Server観点でまとめます。

AND/ORの優先順位による意図しない評価
SQL Serverでは一般にANDがORより先に評価されます。意図した条件にするには括弧で明示するのが安全です。
NULLを含むとUNKNOWNが発生し得る
列 = 値 の比較は、列がNULLだとTRUEにもFALSEにもならずUNKNOWNになり得ます。ORでつないでも最終的にUNKNOWNのままだとWHEREで除外されます。
検索条件は「TRUEの行のみ返る」
OR条件がUNKNOWNに落ちるケースは、結果セットに現れない点を前提に設計します（例：NULLは別条件で明示的に拾う等）。
可読性・保守性の観点
ORを多用すると条件が長くなりやすいため、括弧によるグルーピングや、条件のまとまりを意識した記述が重要です。

OR（Transact-SQL）の使用例

SQL Serverでのsql or の代表的な使い方として、WHERE句で「どちらかを満たす行」を抽出する例を示します。

-- 例：顧客のステータスが 'Active' または 'Trial' の行を取得
SELECT CustomerId, Status
FROM dbo.Customers
WHERE Status = 'Active' OR Status = 'Trial';

また、数値条件を組み合わせて「いずれかの条件で該当する行」を取りたい場合もORは有効です。

-- 例：金額が高額、または優先フラグが立っている注文を取得
SELECT OrderId, Amount, IsPriority
FROM dbo.Orders
WHERE Amount >= 100000 OR IsPriority = 1;

OR条件が複雑になるほど、括弧による条件の塊（意図の固定）が重要になります。読み手が誤解しない形で式を整理するのが、T-SQL運用では特に効果的です。

Azure Synapse Analytics等での例

Azure Synapse AnalyticsのSQL（専用SQLプール／サーバーレスSQLプール）でも、基本的なORの記述はSQL ServerのT-SQLと同様に扱えます。たとえば、ログデータやイベントデータから「いずれかの種別」を抽出するような用途でsql or が使われます。

-- 例：イベント種別が 'click' または 'view' のデータを抽出
SELECT event_time, user_id, event_type
FROM dbo.events
WHERE event_type = 'click' OR event_type = 'view';

分散クエリ環境では、条件式が実行計画やスキャン量に影響することがあります。OR自体の意味は同じでも、対象データ量が大きいほど条件の書き方が重要になりやすい点は意識しておくとよいでしょう。

CREATE OR ALTERの概要と利用シーン

SQL Serverには、オブジェクトを「作成（CREATE）」または「変更（ALTER）」する際に、存在有無を意識せずに一つの文で済ませられるCREATE OR ALTER構文があります。これはOR演算子とは別系統の「OR」ですが、SQL Serverの運用で頻出のため、sql or の関連トピックとして押さえておく価値があります。

代表的な利用シーンは次のとおりです。

デプロイ（リリース）時に、環境によってオブジェクトの有無が異なる可能性がある
CI/CDで同じスクリプトを繰り返し適用したい（冪等性を高めたい）
開発・検証・本番で同一の作成スクリプトを運用したい

従来は「存在チェックしてCREATE/ALTERを分岐」するスクリプトが必要でしたが、CREATE OR ALTERにより記述量と事故リスクを減らせます。

CREATE OR ALTERの詳細と適用条件

CREATE OR ALTERは、対象オブジェクトが存在しなければCREATE、存在すればALTERとして動作します。T-SQLでの典型例は次のようになります（例はストアドプロシージャ）。

CREATE OR ALTER PROCEDURE dbo.usp_Sample
AS
BEGIN
    SELECT GETDATE() AS current_time;
END;

ただし、すべてのオブジェクト種別で無条件に使えるわけではありません。SQL Serverのドキュメント上、CREATE OR ALTERがサポートされるオブジェクト種別・バージョン条件があります。運用上は以下を確認してください。

対象がCREATE OR ALTER対応のオブジェクト種別であること（例：プロシージャ、ビュー、関数、トリガー等は対応しているケースが多い）
使用しているSQL Serverのバージョン／互換性レベルで構文が有効であること
同名オブジェクトが「別スキーマ」に存在するなど、意図しない衝突がないこと

SQL Serverのバージョンが古い場合、CREATE OR ALTERが構文エラーになる可能性があります。適用前に対象環境のバージョンと対応状況を必ず確認してください。

SQL Server 2016での導入に関する補足（更新プログラム／ビルド）

CREATE OR ALTERは、SQL Serverのすべての初期リリースで最初から利用できたわけではなく、バージョンや更新プログラム（CU）適用状況に依存します。SQL Server 2016環境で利用を検討する場合は、少なくとも以下を確認するのが実務的です。

SQL Server 2016のエディションと正確なビルド番号（SELECT @@VERSION; 等で確認）
最新のサービスパック／累積更新プログラム（CU）が適用されているか
本番と開発でビルド差異がないか（スクリプトが片方でだけ通る事故の予防）

特に複数環境にスクリプトを流す運用では、「sql or」のうちCREATE OR ALTERの“OR”が便利な反面、対応していない環境が混ざるとデプロイが止まる原因になります。SQL Server 2016ではビルド前提を明確にしたうえで採用するのが安全です。

OR条件で意図しない結果を防ぐためのチェックポイント

SQLのORは「どちらか一方でも条件を満たせば抽出する」ため便利ですが、書き方やデータの状態によっては想定外に行が増える／減る、あるいは急に遅くなるといった問題が起きやすいポイントでもあります。ここでは、sql or を安全に使うために事前に確認したいチェックポイントを「NULL」「パフォーマンス」「可読性・保守性」の3観点で整理します。

NULLを含む場合の挙動と対処（NULL比較の罠）

OR条件で特に見落とされやすいのが、NULLを含む列の比較です。SQLではNULLは「値がない（不明）」であり、=や<>で比較してもTRUE/FALSEにならず、UNKNOWN（不明）として扱われます。WHERE句はTRUEの行だけを返すため、NULLが絡むと「一致するはずが返らない」ケースが起きます。

罠1：NULLに対して= NULLとしてしまう
col = NULLは常にUNKNOWNになり、行は返りません。NULLを判定したい場合はIS NULLを使います。
```
-- NG
WHERE col = NULL OR col = 'A'

-- OK
WHERE col IS NULL OR col = 'A'
```
罠2：否定条件にNULLが混ざり、期待とズレる
たとえば「A以外」を取りたい意図でcol <> 'A'を書くと、colがNULLの行はUNKNOWNとなり除外されます。NULLも「A以外」に含めたいなら、ORで補う必要があります。
```
-- 「A以外」＋NULLも含めたい
WHERE col <> 'A' OR col IS NULL
```
罠3：ORで片側がTRUEでも、もう片側がUNKNOWNになっても問題ない…と思い込みがち
論理的には「TRUE OR UNKNOWN = TRUE」なので返りそうに見えますが、実際に返るかは式全体がTRUEになるかどうか次第です。NULLを含む比較が複数あると、意図せずUNKNOWNのまま残り、結果が縮むことがあります。OR条件では、NULLをどう扱うか（含める／除外する）を明示するのが安全です。

対処の基本方針は次の通りです。

NULL判定はIS NULL/IS NOT NULLを使う
「NULLを値として扱いたい」場合は、式にNULL用の分岐（例：OR col IS NULL）を足す
NULLを含む列を条件に入れるときは、「NULLは一致扱いか？」を先に決めてSQLへ落とし込む

パフォーマンスの観点（インデックス、ORの分解、UNIONの検討）

sql or は条件が増えるほど柔軟になりますが、検索条件が複雑化するとオプティマイザがインデックスを活かしにくくなり、全表走査や大きな範囲スキャンが発生しやすくなります。とくに大量データのテーブルでは、OR条件がボトルネックになりがちです。

インデックスが効きにくい典型
ORで「異なる列」を条件にする場合、単一のインデックスではカバーしづらく、結果として広い読み取りが起きることがあります。
```
WHERE col_a = 10 OR col_b = 20
```
この場合、col_a用・col_b用にそれぞれインデックスがあっても、DBによっては最適化が難しくなり、期待より遅くなることがあります。
ORの分解を検討する（特に別列ORの場合）
OR条件を2つの検索に分け、結果をまとめることで、各検索がインデックスを使いやすくなるケースがあります。代表例がUNION（重複排除）やUNION ALL（重複許容）です。
```
-- ORの代替案（重複の可能性があるなら UNION で排除）
SELECT ...
FROM t
WHERE col_a = 10
UNION
SELECT ...
FROM t
WHERE col_b = 20
```
ただし、UNIONは重複排除のコストがかかるため、重複しないことが明確ならUNION ALLも候補になります。どちらが速いかはデータ分布や実行計画次第なので、実測が重要です。
同一列のORはINの方が最適化されやすい場合がある
同じ列に対するOR（例：col = 1 OR col = 2）は、後述のINへ寄せると読みやすさだけでなく、DBによっては実行計画が安定することがあります。
実行計画で「どこが遅いか」を確認する
OR条件が原因かどうかは、最終的に実行計画と実測で判断します。インデックスが選ばれているか、フィルタが後段に回っていないか（行を大量に読んでから絞っていないか）を確認し、必要に応じてORの分解や条件の整理を行います。

可読性・保守性を上げる書き方（IN、括弧、条件の整理）

OR条件は増えるほど読みづらくなり、要件変更時の修正ミスも起きやすくなります。結果として「意図しない条件が混ざる」「追加した条件だけ効いていない」などのバグにつながるため、可読性を意識した書き方が重要です。

同一列のORはINでまとめる

同じ列に対して値候補を列挙するなら、ORの羅列よりINの方が短く、差分も見やすくなります。

-- 読みにくい（増えるほど辛い）
WHERE status = 'NEW' OR status = 'OPEN' OR status = 'PENDING'

-- 読みやすい
WHERE status IN ('NEW', 'OPEN', 'PENDING')

括弧で条件のまとまりを明確にする
OR条件が複数あると、どこからどこまでが同じグループの条件かが曖昧になりがちです。意図したまとまりごとに括弧を付け、読む人が一目で判断できる形にします。
```
WHERE
  (type = 'A' OR type = 'B')
  AND is_active = 1
```
「何を満たせばOKか」を先に言語化してからSQLへ落とす
ORは「許可条件」の集合になりやすく、後から条件が増えるたびに破綻しがちです。保守性を上げるには、例えば「許可されるケース」を箇条書きにしてから、それぞれをORで結ぶように組み立てると、漏れや重複に気づきやすくなります。
条件を揃えて整形する（縦に揃える）
ORの多いWHERE句は、インデントと改行を揃えるだけで保守性が上がります。特に「追加・削除」が頻繁なクエリほど、整形ルールを決めておくとレビューもしやすくなります。

OR条件は正しく使えば強力ですが、NULLの扱い・実行速度・読みやすさの3点を押さえるだけで、意図しない結果やトラブルを大きく減らせます。

まとめ（SQLのORを正しく使う要点）

SQLのORは、WHERE句などで「どれか1つでも条件を満たせば対象にする」ための基本的な論理演算子です。便利な一方で、条件の組み合わせ方を誤ると意図しない抽出結果になりやすいため、最後に要点だけを押さえておきましょう。

ORは「いずれかが真なら真」という前提で、条件を足し算的に広げます。絞り込みではなく「候補を増やす」方向に働くため、抽出範囲が想定より広がっていないか確認するのが重要です。
ANDとORが混在する場合は、優先順位の違いで結果が変わりやすい点に注意します。読み手（将来の自分を含む）が意図を誤解しないよう、必要に応じて括弧で条件のまとまりを明確にするのが安全です。
OR条件を複数並べると、可読性が落ちたり修正漏れが起きたりします。候補の列挙が目的なら、状況に応じてIN句で簡潔に表現できないか検討し、保守しやすい書き方を選びましょう。
NULLが絡む比較は、期待どおりに真偽が決まらないケースがあります。ORで条件を増やすほど見落としが起きやすいため、NULLを含む列の扱いは特に慎重に設計・確認することが大切です。
パフォーマンス面でも、ORはクエリ計画に影響しやすい要素です。結果が正しいことを最優先にしつつ、必要に応じて条件の整理や書き方の見直しを行い、読みやすさと速度のバランスを取ります。

sql or を使う際は、「条件が広がる」「優先順位で結果が変わる」「読みやすく保守できる形に整える」という3点を軸に見直すと、意図しない結果や運用トラブルを防ぎやすくなります。