MySQLのIF ELSE IF完全攻略！CASE式と複数条件分岐の書き方

JavaScriptやPHP、Pythonなどの一般的なプログラミング言語からSQLに入ったエンジニアが、開発現場で真っ先に直面する壁の一つが「MySQLでIF〜ELSE IFのような多段の条件分岐をどう書くか」という問題です。直感的にIF ... ELSE IFとクエリに書き込んで構文エラーを出してしまった経験を持つ方は少なくありません。

MySQLにおいて、通常のDML（SELECTやUPDATEなど）で複数条件分岐を行う際は「CASE式」を用いるのが標準仕様です。一方で、2分岐に特化した「IF()関数」や、ストアドプロシージャ内でのみ動作する制御構文「IF ... ELSEIF」が存在するため、用途に応じた正しい構文の選定が不可欠となります。本記事では、複数条件の優先順位やNULL判定、パフォーマンスへの影響、UPDATE文での一括更新テクニックまで、現場で即使える実践ノウハウを徹底的に解説します。

📌 【この記事の重要ポイントまとめ】

• 要点1：通常のSELECT/UPDATE文で「IF〜ELSE IF」を実現するには、ANSI標準であるCASE WHEN ... THEN ... ELSE ... END構文を使用するのが正解。
• 要点2：条件分岐は「上から順に評価」され、最初に合致した条件で確定するため、優先度の高い条件や限定的な条件を上位に記述する設計が必須。
• 要点3：ストアドプロシージャ内ではELSEIF制御構文が使える一方、単一クエリ内での過度なネストやWHERE句での多用はインデックスを無効化させるリスクがある。

【構文の全貌】MySQLで「IF〜ELSE IF」を実現する3つのアプローチ

MySQLで条件分岐を記述する際、実行するコンテキスト（通常のクエリか、ストアドプログラムか）によって利用できる構文が明確に分かれています。まずは全体像を正しく整理しておきましょう。

代表的な手法は以下の3パターンに集約されます。

• 1. CASE式（検索CASE式 / 単純CASE式）： SELECT、UPDATE、INSERT、ORDER BYなど、あらゆるSQL文の式として利用可能な標準仕様。多岐にわたる複数条件分岐の本命。
• 2. IF()関数：IF(条件, 真の値, 偽の値)の形式で記述するMySQL独自の関数。2分岐であれば簡潔に記述可能だが、ネストすると著しく可読性が低下する。
• 3. IF ... ELSEIF制御構文： ストアドプロシージャやストアドファンクション、トリガーなどの手続き型ブロック（BEGIN ... END）の中でのみ実行できるプログラミング的構文。

Webアプリケーションの開発現場で「SQLの中でIF ELSE IFを行いたい」という要件の約9割は、1つ目のCASE式で解決します。

SELECT文で役立つCASE WHEN構文の実践｜複数条件の優先順位と書き方

SELECT文内で複数の条件を順次評価し、それぞれ異なる値を返したい場合、検索CASE式（Searched CASE）を採用するのが最も柔軟で安全です。

検索CASE式の基本構文と実例

SELECT user_id, score, CASE WHEN score >= 90 THEN 'Sランク' WHEN score >= 70 THEN 'Aランク' WHEN score >= 50 THEN 'Bランク' ELSE 'Cランク' END AS user_rank FROM exam_results;

この構文は、プログラミング言語におけるif (score >= 90) { ... } else if (score >= 70) { ... } else { ... }と完全に同等の挙動を示します。

SQL CASE WHENの評価優先順位とショートサーキット

CASE式を扱う上で極めて重要な原則が「条件評価の優先順位（評価順序）」です。

CASE式は上から下に向かって順番に条件式を評価し、真（TRUE）になった時点で対応するTHENの値を返し、それ以降のWHEN句は評価せずに終了します（ショートサーキット評価）。

-- ❌ 誤った順序：狭い条件が評価されないアンチパターン CASE WHEN score >= 50 THEN '合格ライン' WHEN score >= 90 THEN '特待生' -- ここには絶対に到達しない ELSE '不合格' END -- ⭕ 正しい順序：より厳密・限定的な条件を上に配置する CASE WHEN score >= 90 THEN '特待生' WHEN score >= 50 THEN '合格ライン' ELSE '不合格' END

条件が重複しうるケースでは、「最も厳格な条件」を上部に記述することが論理破綻を防ぐ鉄則です。

【徹底比較】CASE式・IF関数・ストアド制御構文の違いと使い分け

開発手法ごとの特性と使い分けの基準を比較表にまとめました。システム要件や保守方針に合わせて適切な構文を選定してください。

IF関数のネストは避けるのが現場のセオリー

MySQLではIF(cond1, val1, IF(cond2, val2, val3))のようにIF関数を入れ子（ネスト）にして多段分岐を再現することも文法上は可能です。しかし、条件が3つを超えた段階で括弧の対応関係が複雑化し、コードレビュー時の視認性が著しく損なわれます。多分岐には無条件でCASE式を選択するのが、品質を担保するエンジニアの共通作法です。

実務で差がつく！UPDATE文でのCASE WHEN活用とバッチ処理高速化

CASE式が真価を発揮するのはSELECT文だけではありません。業務システムにおける「条件に応じた複数行の一括更新（UPDATE）」において絶大な威力を発揮します。

アンチパターン：ループ処理による個別UPDATE

多くの初心者が書いてしまいがちなのが、バックエンド（Node.jsやPython、PHP等）でループを回し、IDごとに別々のUPDATE文を大量発行するパターンです。

-- アプリケーション側でループして1件ずつ実行（通信オーバーヘッドとロック多発の要因） UPDATE products SET price = price * 1.1 WHERE category_id = 1; UPDATE products SET price = price * 1.05 WHERE category_id = 2; UPDATE products SET price = price * 0.9 WHERE category_id = 3;

ベストプラクティス：1クエリに集約するUPDATE CASE WHEN

CASE式をUPDATEのSET句に組み込むことで、1回のクエリ発行で全条件の更新を安全かつ高速に完了させることができます。

UPDATE products SET price = CASE category_id WHEN 1 THEN price * 1.10 WHEN 2 THEN price * 1.05 WHEN 3 THEN price * 0.90 ELSE price END, updated_at = NOW() WHERE category_id IN (1, 2, 3);

この手法により、データベースとの往復遅延（ラウンドトリップタイム）が激減し、大量データを扱う夜間バッチ処理の所要時間を大幅に短縮できます。

一般に知られていない盲点とネットの誤解

ネット上の簡易的な解説記事では見落とされがちな、本番障害に直結する3つの落とし穴を検証します。

1. NULL値の判定における「= NULL」の罠

SQLにおいてNULLは「値が存在しない（不明）」を意味するため、WHEN status = NULLと記述しても絶対にTRUEにはならず、必ずELSE句に落ちてしまいます。NULL判定を行う場合は、必ずIS NULLまたはIS NOT NULLを明記しなければなりません。

-- ❌ 誤り：NULL判定が機能しない CASE WHEN user_status = NULL THEN '未登録' ELSE '登録済' END -- ⭕ 正解：IS NULLを使用する CASE WHEN user_status IS NULL THEN '未登録' ELSE '登録済' END

2. ELSEを省略した際の「暗黙のNULL返却」

CASE式でELSE句を省略した場合、どのWHEN条件にも一致しなかったレコードには自動的にNULLが返されます。これを知らずに「元の値がそのまま維持される」と思い込んでいると、意図しないデータ欠損やフロントエンドでのクラッシュを引き起こします。デフォルト値を維持したい場合は、ELSE 元のカラム名を明示する習慣をつけてください。

3. WHERE句でのCASE式利用によるインデックス無効化

「検索条件を動的に変えたい」という理由で、以下のようにWHERE句の左辺でCASE式を展開する記述が見受けられます。

-- ❌ パフォーマンス劣化：インデックスが使われないフルテーブルスキャン SELECT * FROM orders WHERE (CASE WHEN @type = 'VIP' THEN total_amount >= 100000 ELSE total_amount >= 10000 END); -- ⭕ パフォーマンス最適：標準的な論理演算子（AND / OR）で展開 SELECT * FROM orders WHERE (@type = 'VIP' AND total_amount >= 100000) OR (@type != 'VIP' AND total_amount >= 10000);

カラムに関数やCASE式を噛ませると、B-Treeインデックスの探索が効かなくなり、数百万件規模のテーブルでは致命的なスロークエリへと発展します。

【実態検証】利用者の生の声と現場目線で見えたリアル

国内の開発現場やコミュニティ（Qiita、Zenn、SNSの技術クラスタ）で交わされる議論を分析すると、SQL内の条件分岐に対してエンジニアが直面している葛藤が見えてきます。

実際のコードレビューで頻出する指摘事項として、以下のようなリアルな声が挙げられます。

• 「SQLに長大なCASE文を書くのはやめてほしい」： ビジネスロジックがDB層に散らばり、アプリケーションの単体テストが困難になるというアーキテクチャ上の懸念。
• 「ストアドのIF-ELSEIFがブラックボックス化している」： 過去のレガシーなストアドプロシージャ内で複雑怪奇な分岐が組まれており、怖くてリファクタリングできないという現場の悲鳴。
• 「集計クエリ（SUM + CASE）の爆発的な便利さ」： ピボットテーブルのように行データを列データに展開する集計テクニック（条件付き集約）は、BIツールやダッシュボード構築で依然として圧倒的な支持を得ている。

【プロの結論】条件分岐を「DB側」と「アプリ側」のどちらで持つべきかの判断基準

システム設計における健全な境界線を保つため、以下の判断基準を推奨します。

【mysql if else if】に関するよくある質問（FAQ）

Q1：SELECT文の中でプログラミング言語のように「IF ... ELSEIF」と直接書くことはできますか？
A1：できません。通常のSELECT文やUPDATE文の式として機能するのはCASE WHEN ... THEN ... ELSE ... END構文またはIF()関数です。ELSEIFはストアドプロシージャや関数などのブロック内専用構文となります。

Q2：CASE式とIF()関数で実行速度（パフォーマンス）に大きな差はありますか？
A2：MySQLの内部オプティマイザにおいて、両者の実行速度に体感できるような有意差はありません。そのため、他RDBMSへの移行性（ポータビリティ）とコードの可読性に優れるCASE式の使用が強く推奨されます。

Q3：CASE式の中で別のCASE式を入れ子（ネスト）にすることは可能ですか？
A3：構文上は無制限にネスト可能です。ただし、3階層以上のネストは可読性を著しく破壊するため、論理演算子（AND / OR）を駆使してフラットな1階層のWHEN条件に展開するか、VIEWやサブクエリで前処理を行う設計が推奨されます。

Q4：CASE式の戻り値のデータ型はどう決定されますか？
A4：THEN句およびELSE句で返されるすべての値の型を包括できる、最も汎用的なデータ型に自動変換（集約）されます。例えば、文字列型と数値型が混在していると意図せず文字列型にキャストされる場合があるため、返却する値の型は必ず統一してください。

まとめ：保守性の高いSQLを書くための実践チェックリスト

MySQLにおける条件分岐は、基本を押さえれば極めて強力な武器となります。最後に、本番コードに組み込む前の最終チェックリストを提示します。

• クエリ内の多分岐はIF()の多重ネストではなくCASE WHEN ... ENDで統一しているか
• 条件の優先順位（限定的な条件が上に書かれているか）に論理的な矛盾はないか
• NULL値の判定に= NULLではなくIS NULLを使用しているか
• 予期せぬNULL混入を防ぐため、ELSE句を明示的に記述しているか
• WHERE句の左辺でCASE式を使用してインデックスを破壊していないか

適切なレイヤードアーキテクチャを意識し、データベースの計算能力とアプリケーションの可読性を両立させた堅牢なSQL設計を実践していきましょう。 （出典: mysql if else if（Yahoo!ニュース））