SQL バッチ処理 — UPSERT・一括更新・重複排除の応用

QUESTION 1

UPSERT — INSERT ... ON CONFLICT DO UPDATE で新規・更新を1クエリに統合する

INSERTON CONFLICTUPSERTAPIバッチ同期

前提知識 ▼

UPSERT（Upsert = Update + Insert）は「レコードが存在すれば UPDATE、なければ INSERT」を1クエリで行うパターンです。APIバッチで外部サービスからデータを同期する処理の最頻出パターンです。

INSERT INTO target_table (col1, col2, ...)
VALUES (...)
ON CONFLICT (unique_col)          -- 競合判定に使うユニークキー列を指定
DO UPDATE SET
  col2 = EXCLUDED.col2;          -- EXCLUDED = INSERTしようとした値（競合した新データ）

DO NOTHING を使うと「競合したら何もしない（スキップ）」になります。べき等性（同じデータを何度実行しても結果が変わらない性質）を保証する際に便利です。

EXCLUDED とは？
ON CONFLICT DO UPDATE 内で使える特別なテーブル参照です。「INSERTしようとしたが競合した行の値」を指します。EXCLUDED.col で新しい値を、target_table.col で既存の値を参照できます。

問題 ▼

外部ECサービスから商品マスタを毎日バッチ同期します。products テーブルに 新商品はINSERT、既存商品は name/price/updated_at を UPDATE してください。

同期データ（VALUES に直書きする）：(id: 1, 外部ID: EXT-001, name: ワイヤレスマウス改, price: 3200), (2, EXT-002, メカニカルキーボード, 8900), (3, EXT-003, USBハブ4ポート, 1980)

使用テーブル

▸ products（同期前）

id	external_id (UNIQUE)	name	price	updated_at
1	EXT-001	ワイヤレスマウス	2800	2024-01-10
2	EXT-002	メカニカルキーボード	8900	2024-01-10

期待出力 ▼

id	external_id	name	price	updated_at
1	EXT-001	ワイヤレスマウス改	3200	2024-06-01
2	EXT-002	メカニカルキーボード	8900	2024-06-01
3	EXT-003	USBハブ4ポート	1980	2024-06-01

模範解答コード ▼

INSERT INTO products (id, external_id, name, price, updated_at)
VALUES
  (1, 'EXT-001', 'ワイヤレスマウス改', 3200, '2024-06-01'),
  (2, 'EXT-002', 'メカニカルキーボード', 8900, '2024-06-01'),
  (3, 'EXT-003', 'USBハブ4ポート', 1980, '2024-06-01')
ON CONFLICT (external_id)           -- unique制約違反（競合）時の処理を指定
DO UPDATE SET                       -- 競合時は以下の列を更新（UPSERT）
  name       = EXCLUDED.name,       -- EXCLUDED = 挿入しようとした新データ
  price      = EXCLUDED.price,
  updated_at = EXCLUDED.updated_at;

SELECT id, external_id, name, price, updated_at
FROM products
ORDER BY id;

/*
  実行順序:
  1. VALUES        → 挿入する行を準備
  2. INSERT        → 各行を挿入試行
  3. ON CONFLICT   → 重複を判定
  4. DO UPDATE SET → 競合行を新値で上書き
  5. SELECT         → 同期後の状態を検証
*/

解説（テーブル変化・ポイント） ▼

INSERT INTO products (id, external_id, name, price, updated_at)
VALUES
  (1, 'EXT-001', 'ワイヤレスマウス改', 3200, '2024-06-01'),
  (2, 'EXT-002', 'メカニカルキーボード', 8900, '2024-06-01'),
  (3, 'EXT-003', 'USBハブ4ポート', 1980, '2024-06-01')
ON CONFLICT (external_id)
DO UPDATE SET
  name       = EXCLUDED.name,
  price      = EXCLUDED.price,
  updated_at = EXCLUDED.updated_at;

SELECT id, external_id, name, price, updated_at
FROM products
ORDER BY id;

LEGEND ▼

データ取得・読込対象

① 同期前の状態 ▼

products テーブル（同期前）同期前の products テーブルです。id=1 (EXT-001) と id=2 (EXT-002) が存在します。external_id 列には UNIQUE 制約が設定されています。

1 / 4

id	external_id	name	price	updated_at
1	EXT-001	ワイヤレスマウス	2800	2024-01-10
2	EXT-002	メカニカルキーボード	8900	2024-01-10

既存 2行

学習ポイント

超基礎補足（UPSERTの仕組み）：データベースの基本は「作成(INSERT)・読み取り(SELECT)・更新(UPDATE)・削除(DELETE)」です。通常、既に存在するIDをINSERTするとエラーになりますが、ON CONFLICT を使うとエラーを回避し「存在すればUPDATEする」という安全な動作に切り替えられます。

バッチ同期の定番パターン：外部API・CSVからデータを取り込む処理では「全DELETE→全INSERT」より UPSERT の方が安全。トランザクション中にデータが一瞬消えない、部分失敗時にロールバックしやすい。

updated_at の無駄な更新を防ぐ：上記のクエリでは EXT-002 のように値が同じでも updated_at が上書きされてしまいます。DO UPDATE SET ... WHERE EXCLUDED.price <> products.price のように WHERE を付けると「実際に値が変わった行だけ UPDATE」でき、ログや負荷の観点で実用的です。

アンチパターン

UNIQUE制約なしで ON CONFLICT を使う：ON CONFLICT の対象列には UNIQUE制約またはUNIQUEインデックスが必須。なければ「ERROR: there is no unique or exclusion constraint」が発生する。

PKをDO UPDATE SETに含める：id = EXCLUDED.id と書くと自動採番のPKを書き換えようとしてエラーになる。PKと external_id（競合キー）は SET に含めないこと。

実務コラム

バッチの冪等性（べきとうせい）を担保する
実務のバッチ処理において、「途中でエラーになったからもう一度実行する」というシーンは日常茶飯事です。もし通常の INSERT しか使っていないと、再実行時に「既に存在するID」としてエラーになり、手動でデータを直す羽目になります。UPSERTをデフォルトの選択肢にしておくことで、「何度実行しても同じ正しい状態になる（冪等性）」という、運用に強いバッチを作ることができます。

QUESTION 2

UPDATE FROM — 別テーブルを参照して複数行を一括更新する

UPDATEFROMJOIN UPDATEバッチ価格改定

前提知識 ▼

UPDATE ... FROM は、別テーブルの値を参照しながら対象テーブルを一括更新するパターンです。「価格改定マスタに基づいて商品テーブルを更新する」「承認済みリストと突合してステータスを変更する」など、バッチ処理の核心です。

UPDATE target                        -- 更新対象テーブル
SET    col = src.col                -- 参照元テーブルの値をセット
FROM   source src                   -- 参照元テーブル（JOIN的に結合）
WHERE  target.key = src.key;       -- 結合条件（これがないと全件更新になる！）

PostgreSQL では UPDATE ... FROM、MySQL では UPDATE target JOIN source ON ... の構文を使います。

WHERE 結合条件を忘れると全行更新：FROM を書いただけで WHERE の結合条件を省くと、対象テーブルの全行が更新されます。必ず結合キーのWHERE条件を付けること。

問題 ▼

price_updates（価格改定マスタ）テーブルの内容を使って、products テーブルの price と updated_at を一括更新してください。price_updates に存在する product_id の行だけ更新対象です。

使用テーブル

▸ products（更新前）

product_id	name	price	updated_at
101	コーヒー豆A	1200	2024-01-01
102	コーヒー豆B	1500	2024-01-01
103	紅茶葉C	900	2024-01-01
104	緑茶D	800	2024-01-01

▸ price_updates（価格改定マスタ）

product_id	new_price	applied_at
101	1380	2024-06-01
103	1050	2024-06-01

期待出力 ▼

product_id	name	price	updated_at
101	コーヒー豆A	1380	2024-06-01
102	コーヒー豆B	1500	2024-01-01
103	紅茶葉C	1050	2024-06-01
104	緑茶D	800	2024-01-01

模範解答コード ▼

UPDATE products
SET
  price      = pu.new_price,                -- 参照元(pu)の新価格を代入
  updated_at = pu.applied_at                -- 参照元(pu)の適用日を代入
FROM   price_updates pu                     -- 参照元のテーブルを指定 (puはエイリアス)
WHERE  products.product_id = pu.product_id; -- 更新対象を絞り込む結合条件

/*
  実行順序:
  1. FROM  → 行を読み込む
  2. WHERE → 結合して更新対象を絞り込む
  3. SET   → 一致行を新値で上書き
*/

解説（テーブル変化・ポイント） ▼

UPDATE products
SET
  price      = pu.new_price,
  updated_at = pu.applied_at
FROM   price_updates pu
WHERE  products.product_id = pu.product_id;

LEGEND ▼

データ取得・読込対象

① 2テーブルの準備 ▼

products ⋈ price_updatesUPDATE 対象の products と参照元の price_updates を準備します。price_updates には product_id 101・103 の2件だけが存在します。

1 / 3

▸ products（更新対象）

product_id	name	price	updated_at
101	コーヒー豆A	1200	2024-01-01
102	コーヒー豆B	1500	2024-01-01
103	紅茶葉C	900	2024-01-01
104	緑茶D	800	2024-01-01

⋈

▸ price_updates（参照元）

product_id	new_price	applied_at
101	1380	2024-06-01
103	1050	2024-06-01

左: 4行 / 右: 2行

学習ポイント

超基礎補足（エイリアスとJOINの概念）：テーブル名 AS 別名（ASは省略可）と書くことで、SQL内で長いテーブル名を短く呼べます。本問の FROM price_updates pu はその典型です。また、別々のテーブルを特定の共通キー（ここではproduct_id）で結びつけることを「JOIN（結合）」と呼びます。

バッチ一括更新のパフォーマンス：1件ずつループで UPDATE するより、UPDATE FROM で1クエリにまとめる方が圧倒的に速い。N回のDB往復が1回になりラウンドトリップコストが激減する。

CTE を使った UPDATE：WITH updated AS (SELECT ...) UPDATE products SET ... FROM updated WHERE ... のようにCTEで参照元を整形してから UPDATE できる。複雑な集計結果で更新したい場合に有効。

アンチパターン

FROM の結合条件を WHERE に書き忘れる：UPDATE products SET price = pu.new_price FROM price_updates pu; — WHERE がないと price_updates の最初の1行の値で全productが更新される壊滅的バグ。必ず WHERE に結合条件を書くこと。

MySQLで同じ構文を使う：MySQL は UPDATE ... FROM 非対応。UPDATE products p JOIN price_updates pu ON p.product_id = pu.product_id SET p.price = pu.new_price と書く。

実務コラム

ロックの長時間化とチャンク分割
数十万件のレコードを1クエリで UPDATE FROM すると、対象のテーブルに長時間ロックがかかり、並行して動いているユーザー向けのAPIがタイムアウト（DB接続待ち）を起こす事故に繋がります。実務で大規模な更新を行う場合は、一度に数千〜数万件ずつ更新する「チャンク分割」を行い、間に少しスリープを挟むことで、オンライン処理への影響を抑えるのが鉄則です。

QUESTION 3

INSERT INTO ... SELECT — 条件に合う行を別テーブルへ一括移送・アーカイブする

INSERT INTOSELECTアーカイブバッチ移送

前提知識 ▼

INSERT INTO ... SELECT は SELECT の結果をそのまま別テーブルに挿入するパターンです。「古いデータをアーカイブテーブルへ移す」「集計結果をサマリテーブルに書き込む」バッチ処理で多用されます。

INSERT INTO archive_table (col1, col2, ...)
SELECT       col1, col2, ...          -- SELECTの列順と型がINSERT先と一致する必要がある
FROM         source_table
WHERE        条件;                    -- 移送対象を絞る条件

アーカイブ後に元テーブルから削除する場合は DELETE + INSERT INTO...SELECT をトランザクションでセットにします。これで「移送中の消失」を防げます。

VALUES は不要：INSERT INTO ... SELECT では VALUES 句を書きません。SELECT の結果がそのまま挿入される行データになります。

問題 ▼

orders テーブルから 2024年1月以前（order_date < '2024-02-01'）のcompleted注文 を orders_archive テーブルへ一括コピーしてください。コピー後に archived_at 列には現在時刻を設定します。

使用テーブル

▸ orders

order_id	customer_id	amount	status	order_date
1001	C01	12000	completed	2024-01-15
1002	C02	8500	cancelled	2024-01-20
1003	C03	15000	completed	2024-01-28
1004	C01	9200	completed	2024-02-05
1005	C04	6700	completed	2024-02-10

▸ orders_archive（挿入先・初期空）

order_id	customer_id	amount	status	order_date	archived_at
（空）

期待出力 ▼

order_id	customer_id	amount	status	order_date	archived_at
1001	C01	12000	completed	2024-01-15	2024-06-01 02:00:00
1003	C03	15000	completed	2024-01-28	2024-06-01 02:00:00

模範解答コード ▼

BEGIN;

-- ① アーカイブ対象を抽出して orders_archive へ挿入
INSERT INTO orders_archive (
  order_id, customer_id, amount, status, order_date, archived_at
)
SELECT
  order_id, customer_id, amount, status, order_date, NOW()
FROM  orders
WHERE order_date < '2024-02-01'
  AND status     = 'completed';

-- ② 挿入が成功したら元テーブルから削除
DELETE FROM orders
WHERE order_date < '2024-02-01'  -- 抽出時と必ず同じ条件にする
  AND status     = 'completed';

COMMIT;

/*
  実行順序:
  1. BEGIN         → トランザクション開始
  2. FROM / WHERE  → 対象行を絞り込む
  3. INSERT        → 抽出結果を退避先へ挿入
  4. DELETE        → 元表から同条件の行を削除
  5. COMMIT        → 変更を確定
*/

解説（テーブル変化・ポイント） ▼

BEGIN;
INSERT INTO orders_archive
  (order_id, customer_id, amount,
   status, order_date, archived_at)
SELECT
  order_id, customer_id, amount,
  status, order_date, NOW()
FROM  orders
WHERE order_date < '2024-02-01'
  AND status = 'completed';
DELETE FROM orders
WHERE order_date < '2024-02-01'
  AND status = 'completed';
COMMIT;

LEGEND ▼

データ取得・読込対象

① FROM orders ▼

FROM orders — 全行を読込orders テーブル全5行を読み込みます。次のステップで2つの WHERE 条件（日付・ステータス）を組み合わせて移送対象を絞り込みます。

1 / 4

order_id	customer_id	amount	status	order_date
1001	C01	12000	completed	2024-01-15
1002	C02	8500	cancelled	2024-01-20
1003	C03	15000	completed	2024-01-28
1004	C01	9200	completed	2024-02-05
1005	C04	6700	completed	2024-02-10

全 5行読込

学習ポイント

超基礎補足（INSERT ... SELECT文）：通常、データを追加する時は VALUES (値1, 値2) と直書きしますが、大量のデータを別のテーブルから移したい場合は SELECT の結果をそのまま INSERT に流し込むことができます。列の順番とデータ型を一致させることが必須です。

アーカイブバッチの実務パターン：本番テーブルが肥大化するとINDEXサイズも増えクエリが遅くなる。定期的に古いデータを archive テーブルや別DBへ移送することで本番テーブルをスリムに保てる。

CREATE TABLE AS SELECT（CTAS）：テーブルを作りながら同時にデータを挿入する CREATE TABLE new_tbl AS SELECT ... FROM ... も覚えておくと便利。一時集計テーブルの作成に多用される。

アンチパターン

INSERT と DELETE の WHERE 条件がズレる：INSERTは「1月以前」でDELETEは「1月まで（<= '2024-01-31'）」のような微妙な差でデータが残ったり消えたりする。コピペして完全に同一にするか、CTEで一度だけ条件を書くこと。

巨大テーブルを一度に全移送する：数百万件を1トランザクションで移送するとロックが長時間かかりAPIが詰まる。WHERE order_id BETWEEN ? AND ? でページング分割して小分けに実行すること。

実務コラム

パーティショニングによるモダンな運用
毎月数千万件のデータが生まれるシステムでは、バッチによる DELETE や移送でさえDBの負荷になります。モダンな設計では、PostgreSQLなどの「テーブルパーティショニング（月ごとに物理的にファイルを分ける機能）」を使い、古い月のパーティションを DROP TABLE で一瞬で消し飛ばす、あるいはそのままアーカイブ用DBにアタッチする手法がとられます。

QUESTION 4

ROW_NUMBER 重複排除 — 同一キーの最新レコードだけをCTEで抽出する

ROW_NUMBERCTE重複排除データクレンジング

前提知識 ▼

バッチ取込みや二重送信でテーブルに同一キーの重複が生じることがあります。ROW_NUMBER() を CTE と組み合わせることで「同一キーの中で最新の1件だけを残す」クレンジング処理が書けます。

WITH ranked AS (
  SELECT *,
    ROW_NUMBER() OVER (
      PARTITION BY dup_key           -- 重複を判定するキー列
      ORDER BY     created_at DESC  -- 最新順に番号を振る（1が最新）
    ) AS rn
  FROM target_table
)
SELECT * FROM ranked WHERE rn = 1;  -- 各グループの1位（最新）だけ取得

CTEとは？（Common Table Expression）
WITH 名前 AS (SELECT ...) で一時的な名前付き結果セットを定義します。本体クエリから 名前 でその結果を参照できます。サブクエリをネストするより可読性が高く、バッチ処理の定番書き方です。

問題 ▼

user_events テーブルには同じ user_id と event_type の組み合わせが複数回バッチ取込みされた重複データがあります。user_id + event_type ごとに最新の1件だけを残すクエリを書いてください。

使用テーブル

▸ user_events（重複あり）

event_id	user_id	event_type	payload	created_at
1	U01	login	ip:1.2.3.4	2024-06-01 09:00
2	U01	login	ip:5.6.7.8	2024-06-01 12:00
3	U01	purchase	item:A	2024-06-01 10:00
4	U02	login	ip:9.9.9.9	2024-06-01 11:00
5	U01	purchase	item:B	2024-06-01 15:00

期待出力 ▼

event_id	user_id	event_type	payload	created_at	rn
2	U01	login	ip:5.6.7.8	2024-06-01 12:00	1
5	U01	purchase	item:B	2024-06-01 15:00	1
4	U02	login	ip:9.9.9.9	2024-06-01 11:00	1

模範解答コード ▼

-- ① 一時的なテーブル（CTE）を定義し、各グループ内で最新順に連番を振る
WITH ranked AS (
  SELECT *,
    ROW_NUMBER() OVER (
      PARTITION BY user_id, event_type  -- user_id と event_type でグループ化
      ORDER BY     created_at DESC      -- グループ内で新しい順に並び替え
    ) AS rn
  FROM user_events
)
-- ② CTEから rn=1（最新1件）だけを取得
SELECT
  event_id, user_id, event_type, payload, created_at, rn
FROM  ranked
WHERE rn = 1                            -- rn=2以降（重複）を除外
ORDER BY user_id, event_type;

/*
  実行順序:
  1. CTE定義（ROW_NUMBER） → ウィンドウ関数を評価（行数は保持）
  2. FROM ranked / WHERE   → 行を絞り込む
  3. SELECT / ORDER BY     → 並び替えて出力
*/

解説（テーブル変化・ポイント） ▼

WITH ranked AS (
  SELECT *,
    ROW_NUMBER() OVER (
      PARTITION BY user_id, event_type
      ORDER BY     created_at DESC
    ) AS rn
  FROM user_events
)
SELECT
  event_id, user_id, event_type,
  payload, created_at, rn
FROM  ranked
WHERE rn = 1
ORDER BY user_id, event_type;

LEGEND ▼

データ取得・読込対象

① FROM user_events ▼

FROM user_events — 全行読込user_events テーブル全5行を読み込みます。U01/login・U01/purchase がそれぞれ2件ずつ重複しています。次のステップで PARTITION BY によりグループ分けします。

1 / 5

event_id	user_id	event_type	payload	created_at
1	U01	login	ip:1.2.3.4	2024-06-01 09:00
2	U01	login	ip:5.6.7.8	2024-06-01 12:00
3	U01	purchase	item:A	2024-06-01 10:00
4	U02	login	ip:9.9.9.9	2024-06-01 11:00
5	U01	purchase	item:B	2024-06-01 15:00

全 5行読込

学習ポイント

超基礎補足（WITH句 / CTE）：WITH 名前 AS (SELECT ...) は「共通テーブル式(CTE)」と呼ばれ、複雑なSQLをわかりやすく分割する機能です。一時的なビューを作るような感覚で、メインのSELECT文から呼び出して使うことができます。

冪等なバッチ設計との組み合わせ：バッチを2回走らせても重複が残らないよう「取込み後に重複排除」または「UPSERT で取込む」を設計段階で選択する。ROW_NUMBER重複排除は後者が使えない場合のセーフティネット。

DELETEへの変換パターン：SELECTで残す行を確認してからDELETEに変えると安全。DELETE FROM user_events WHERE event_id NOT IN (SELECT event_id FROM ranked WHERE rn=1) でも同じ意味になる。

アンチパターン

DISTINCT で解決しようとする：DISTINCT は全列が同一の行しか除去できない。event_id が異なる「論理的重複」には使えない。ROW_NUMBER が正解。

RANK を使うと同時刻で複数残る：created_at が完全に同じ行が2件あると RANK/DENSE_RANK では両方 rn=1 になってしまう。「必ず1件」保証したいなら ROW_NUMBER を使い、event_id などでORDERを追加する。

実務コラム

分散システムと「At-Least-Once」配信
KafkaやSQSのようなメッセージキューを使ったイベント駆動アーキテクチャでは、ネットワークの瞬断などにより「同じイベントが複数回届く（At-Least-Once）」ことが仕様上避けられません。そのため、データレイクやDWHに取り込んだ後、分析や連携に使う前段階（クレンジング層）で、この ROW_NUMBER を使った重複排除バッチを噛ませるのが標準的なデータパイプラインの設計です。

QUESTION 5

CASE WHEN 一括ステータス更新 — 条件別に異なる値をSETする1クエリ更新

UPDATECASE WHENステータス遷移バッチ状態管理

前提知識 ▼

バッチ処理でよくある「複数の条件ごとに異なる値にUPDATEしたい」場面では、SET 句に CASE WHEN を使うことで1クエリにまとめられます。

UPDATE orders
SET status =
  CASE
    WHEN 条件A THEN 'value_a'   -- 条件Aに合う行はvalue_aに更新
    WHEN 条件B THEN 'value_b'   -- 条件Bに合う行はvalue_bに更新
    ELSE              status       -- どの条件にも合わない行は現状維持
  END
WHERE 絞り込み条件;               -- UPDATE対象を限定（重要）

ELSE の重要性：ELSE を省略すると条件に合わない行の値が NULL になってしまいます。「変更しない」意図なら必ず ELSE 列名（現状維持）か ELSE '適切なデフォルト' を書きましょう。

問題 ▼

夜間バッチで jobs テーブルのステータスを一括更新します。以下のルールで status を変更してください。

retry_count が 0 かつ status = 'failed' → 'pending'（再キュー）
retry_count が 3 以上かつ status = 'failed' → 'abandoned'（諦め）
started_at が NULL かつ status = 'running' → 'stalled'（ゾンビ検知）
上記以外は変更しない

使用テーブル

▸ jobs（更新前）

job_id	status	retry_count	started_at
J01	failed	0	2024-06-01
J02	failed	3	2024-06-01
J03	running	0	NULL
J04	completed	0	2024-06-01
J05	failed	1	2024-06-01

期待出力 ▼

job_id	status（更新後）	変化
J01	pending	failed(0) → pending
J02	abandoned	failed(3) → abandoned
J03	stalled	running(NULL) → stalled
J04	completed	変化なし
J05	failed	変化なし（retry_count=1）

模範解答コード ▼

UPDATE jobs
SET status =
  CASE
    WHEN status = 'failed' AND retry_count = 0 THEN 'pending'   -- ① 再キュー
    WHEN status = 'failed' AND retry_count >= 3 THEN 'abandoned' -- ② 諦め
    WHEN status = 'running' AND started_at IS NULL THEN 'stalled' -- ③ ゾンビ検知
    ELSE status                                                 -- ④ 条件外は現状維持
  END
WHERE status IN ('failed', 'running');                          -- 事前に更新対象を絞り込む

/*
  実行順序:
  1. WHERE → 更新対象を絞り込む
  2. CASE  → 各行の値を評価
  3. SET   → 採用値で列を上書き
*/

解説（テーブル変化・ポイント） ▼

UPDATE jobs
SET status =
  CASE
    WHEN status = 'failed' AND retry_count = 0
      THEN 'pending'
    WHEN status = 'failed' AND retry_count >= 3
      THEN 'abandoned'
    WHEN status = 'running' AND started_at IS NULL
      THEN 'stalled'
    ELSE status
  END
WHERE status IN ('failed', 'running');

LEGEND ▼

データ取得・読込対象

① FROM jobs ▼

FROM jobs — 全行スキャン対象jobs テーブル全5行を読み込みます。次のステップで WHERE IN により failed・running 以外の行を最初に除外して処理を軽くします。

1 / 4

job_id	status	retry_count	started_at
J01	failed	0	2024-06-01
J02	failed	3	2024-06-01
J03	running	0	NULL
J04	completed	0	2024-06-01
J05	failed	1	2024-06-01

全 5行

学習ポイント

超基礎補足（IN演算子とIS NULL）：WHERE status IN ('A', 'B') は status = 'A' OR status = 'B' と同じ意味で、短く書ける便利な文法です。また、値が空（NULL）かどうかを判定するときは = NULL ではなく IS NULL を使わなければならないというSQL特有の絶対ルールがあります。

バッチ状態機械の実装：ジョブキューやワークフローエンジンでは「ステータス遷移」をバッチで一括処理することが多い。CASE WHEN UPDATE はその定番実装。コード上に状態遷移ルールが1箇所にまとまるため可読性が高い。

WHERE と CASE の二重絞り込み：WHERE で更新対象外の行を最初に除外してから CASE を適用することで、DBがスキャンする行数を減らせる。completed な行は最初から読まない。

アンチパターン

条件ごとに UPDATE を複数回に分ける：3パターンを3回の UPDATE で書くと（1）DBへのトリップが3回、（2）最初のUPDATEで変わった行が次のUPDATE条件に引っかかる可能性がある。1クエリ CASE WHEN が安全かつ高速。

実務コラム

ステータス変更履歴（Audit Log）の同時保存
実務では「いつ、どのジョブが、なぜ失敗になったのか」を後から追跡できるようにすることが求められます。ステータスを UPDATE 分だけでなく、同時に job_history のような監査テーブルへ「変更前・変更後・変更理由」を INSERT して履歴を残す設計にすると、運用時のトラブルシューティングが格段に楽になります。