SQL パフォーマンス最適化 — INDEX設計・LATERALの応用

QUESTION 1

日付の半開区間 — 関数とBETWEENの罠を範囲条件で断つ

半開区間date_truncBETWEENRange Scan

前提知識 ▼

「2026年5月の注文」のような期間抽出で date_trunc('month', ordered_at) = '2026-05-01' と書くと、列が関数で包まれて index が使えません（Sargable 違反）。さらに BETWEEN '2026-05-01' AND '2026-05-31' もタイムスタンプ列では危険で、5月31日の 00:00:00 より後の行が全て漏れます。正解は半開区間（開始以上・終了「未満」）です。

-- ✗ 列を関数で包む → 全行で関数評価 = Seq Scan
WHERE date_trunc('month', ordered_at) = '2026-05-01'

-- ✗ BETWEEN は「両端を含む」→ 5/31 00:00:00 を超える行が漏れる
WHERE ordered_at BETWEEN '2026-05-01' AND '2026-05-31'

-- ✓ 半開区間：index が効き、月末の端まで正確
WHERE ordered_at >= '2026-05-01' AND ordered_at < '2026-06-01'

半開区間が正解な理由：「終了側を < 翌期間の先頭」にすると、秒・ミリ秒の端数を一切考えなくてよいうえ、月末日数（28/30/31日）の場合分けも不要になります。日付でも月でも年でも同じ形で書ける、期間条件の万能フォームです。

問題 ▼

orders テーブル（実体300万行）の ordered_at（timestamp）にはインデックス idx_orders_ordered_at があります。2026年5月の注文を、index が効き、かつ月末の端数秒まで漏れなく ordered_at 昇順で取得してください。出力列は order_id, ordered_at, amount。

使用テーブル

- orders（ordered_at は timestamp / index あり）

order_id	ordered_at	amount
1	2026-04-30 23:59:59	700
2	2026-05-01 00:00:00	3400
3	2026-05-14 12:30:00	800
4	2026-05-20 18:05:00	950
5	2026-05-31 23:59:59.9	2600
6	2026-06-01 00:00:00	1500

期待出力 ▼

order_id	ordered_at	amount
2	2026-05-01 00:00:00	3400
3	2026-05-14 12:30:00	800
4	2026-05-20 18:05:00	950
5	2026-05-31 23:59:59.9	2600

模範解答コード ▼

SELECT   order_id, ordered_at, amount
FROM     orders
WHERE    ordered_at >= TIMESTAMP '2026-05-01'  -- 開始：5月の先頭「以上」
  AND    ordered_at <  TIMESTAMP '2026-06-01'  -- 終了：翌月の先頭「未満」（半開区間）
ORDER BY ordered_at;                           -- index の並びと同じ → 追加ソート不要

/*
  実行順序:
  1. idx_orders_ordered_at を二分探索  → 区間の先頭へジャンプ
  2. 葉ブロックを時刻順に右へ走査               → 連続走査
  3. 区間の終端で走査終了                   → 区間外は未走査
  4. index 順 = ordered_at 昇順      → ソート工程なしで返却
  */

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

SELECT   order_id, ordered_at, amount
FROM     orders
WHERE    ordered_at >= '2026-05-01'
  AND    ordered_at <  '2026-06-01'
ORDER BY ordered_at;

LEGEND ▼

データ取得・読込対象

1. 対象テーブル — 月の境界に注目 ▼

FROM orders性能と正しさの両方を試すデータです。id=1 と id=6 は5月の外側ギリギリ、id=5 は5月の内側ギリギリ（23:59:59.9）。境界の4行をどう扱うかで書き方の良し悪しが露わになります。

1 / 5

order_id	ordered_at	amount
1	2026-04-30 23:59:59	700
2	2026-05-01 00:00:00	3400
3	2026-05-14 12:30:00	800
4	2026-05-20 18:05:00	950
5	2026-05-31 23:59:59.9	2600
6	2026-06-01 00:00:00	1500

6行（実テーブルは300万行）

学習ポイント

「列は素のまま・条件側を加工する」が期間抽出の鉄則：date_trunc(列) = 値 は列を加工していますが、半開区間は境界値（定数）の側を加工しています。定数は実行前に1回計算されるだけなので index に乗ります。「月初を求める計算」自体は悪ではなく、どちら側に書くかがすべてです（例：ordered_at >= date_trunc('month', now()) は OK）。

BETWEEN は「離散値」専用と心得る：BETWEEN は両端を含む閉区間なので、整数や DATE 型のような離散的な値には安全です。しかし timestamp のような連続値では「終端の1日 = その日の 00:00:00」となり端数が漏れます。<= '…23:59:59' と書いて逃げるのも、ミリ秒・マイクロ秒精度の値で再び漏れるため不可。連続値の期間は常に半開区間です。

::date キャストも同罪：WHERE ordered_at::date = '2026-05-14' も「列を加工する」形なので Seq Scan になります。1日分の抽出も >= '2026-05-14' AND < '2026-05-15' の半開区間に統一すれば、月次・日次・任意期間がすべて同じパターンで書けます。

アンチパターン

EXTRACT(YEAR ...) AND EXTRACT(MONTH ...) で月を絞る：EXTRACT(YEAR FROM ordered_at) = 2026 AND EXTRACT(MONTH FROM ordered_at) = 5 は関数2連発で index が完全に死ぬうえ、年をまたぐ範囲指定への拡張もできません。レポート系SQLに頻出する書き方ですが、見つけたら半開区間へ書き換える価値が常にあります。

アプリ側で「月末日」を計算して渡す：「5月の終わり = 5/31」をアプリで計算して BETWEEN に渡す設計は、月末日数のバグ（うるう年の2月など）と端数漏れの二重リスクです。渡すのは常に「翌期間の先頭」にすれば、計算は「月初に1ヶ月足す」だけで済みます。

実務コラム：タイムゾーンと「1日」の境界

timestamptz 列を使う国際サービスでは「2026-05-01 とはどこの 0時か」が次の論点になります。WHERE ordered_at >= '2026-05-01' と裸で書くとセッションの TimeZone 設定に依存して境界がズレるため、業務上の基準タイムゾーンを明示（'2026-05-01 00:00:00+09' や AT TIME ZONE）するのが安全です。重要なのは、タイムゾーン変換も「定数側」で行えば index は無傷だということ。列側に ordered_at AT TIME ZONE 'Asia/Tokyo' を掛けた瞬間に Seq Scan へ戻ります。次の Q2 では、絞り込みが2条件以上になったときの「複合 index の列順設計」を見ます。

QUESTION 2

複合インデックスの列順 — 「等値 → 範囲 → 並び」で設計する

複合index列順等値→範囲ソート省略

前提知識 ▼

複合インデックス (A, B) は「A で並べ、A が同じ中で B で並べる」電話帳（姓 → 名）構造です。この構造を最大限使える条件の形は「等値 → 範囲 → 並び替え」：先頭列を等値（=）で固定すると、その内側で次の列がきれいに整列した連続区間になり、範囲条件と ORDER BY までまとめて index に乗ります。

-- index (status, shipped_at) に対して：
WHERE status = 'shipped'              -- 1. 等値で先頭列を固定（区間を1点に）
  AND shipped_at >= '2026-06-01'      -- 2. 固定した区間内の範囲走査
ORDER BY shipped_at                    -- 3. 区間内は整列済み → ソート不要

逆順 (shipped_at, status) だと？範囲条件の列が先頭だと、範囲内のあらゆる status が混在した広い区間を読みながら status を1行ずつ判定するハメになります。「等値で絞れる列を左、範囲・ソートの列を右」——複合 index 設計の最重要原則です。

問題 ▼

shipments テーブル（実体200万行）には複合インデックス idx_ship_status_date (status, shipped_at) があります。ステータスが 'shipped' で、2026年6月1日以降に出荷されたレコードを、この index だけで絞り込みとソートが完結する形で shipped_at 昇順に取得してください。出力列は ship_id, status, shipped_at, dest。

使用テーブル

- shipments（(status, shipped_at) に複合 index）

ship_id	status	shipped_at	dest
1	pending	2026-06-02	Tokyo
2	shipped	2026-05-28	Osaka
3	shipped	2026-06-01	Tokyo
4	delivered	2026-06-03	Nagoya
5	shipped	2026-06-04	Sapporo
6	pending	2026-05-30	Fukuoka
7	shipped	2026-06-09	Tokyo
8	delivered	2026-06-05	Kobe

期待出力 ▼

ship_id	status	shipped_at	dest
3	shipped	2026-06-01	Tokyo
5	shipped	2026-06-04	Sapporo
7	shipped	2026-06-09	Tokyo

模範解答コード ▼

SELECT   ship_id, status, shipped_at, dest
FROM     shipments
WHERE    status = 'shipped'                -- 等値：index 先頭列を1点に固定
  AND    shipped_at >= DATE '2026-06-01'  -- 範囲：固定区間内を連続走査
ORDER BY shipped_at;                        -- 区間内は整列済み → ソート省略

/*
  実行順序:
  1. idx_ship_status_date を複合キーで二分探索  → status 区間へ
  2. 区間内の開始点へ直行                       → 範囲の先頭
  3. shipped_at 順に右へ走査                → 連続走査
  4. status が変わったら走査終了                → 範囲の上限
  5. index の並びが ORDER BY を満たす         → Sort 工程なし
  */

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

SELECT   ship_id, status, shipped_at, dest
FROM     shipments
WHERE    status = 'shipped'
  AND    shipped_at >= '2026-06-01'
ORDER BY shipped_at;

LEGEND ▼

データ取得・読込対象

1. 対象テーブル — status と shipped_at の2条件 ▼

FROM shipments絞り込み条件は status（等値）と shipped_at（範囲）の2つ、さらに shipped_at でのソートも要求されています。この3つの仕事を index 1本に乗せられるかが論点です。

1 / 5

ship_id	status	shipped_at	dest
1	pending	2026-06-02	Tokyo
2	shipped	2026-05-28	Osaka
3	shipped	2026-06-01	Tokyo
4	delivered	2026-06-03	Nagoya
5	shipped	2026-06-04	Sapporo
6	pending	2026-05-30	Fukuoka
7	shipped	2026-06-09	Tokyo
8	delivered	2026-06-05	Kobe

8行（実テーブルは200万行）

学習ポイント

複合 index は「左端から連続して」しか使えない：(status, shipped_at) に対して WHERE shipped_at >= ... だけのクエリは、電話帳で「名前が "太郎" の人」を探すのと同じで先頭列をスキップできず、index をほぼ活かせません（左端一致の原則）。「この index はどんな WHERE の形に効くか」を左から読む習慣をつけてください。

範囲条件より右の列は「整列保証」が切れる：(A, B, C) で A=等値、B=範囲としたとき、C の整列は B の各値の内側でしか成立しないため、ORDER BY C はソート省略になりません。等値 → 範囲 → ソートの順に列を並べ、範囲に使う列は1つまでが複合 index 設計の実務指針です。

選択性ではなく「使い方」で列順を決める：「カーディナリティの高い列を先頭に」という古い経験則より、等値で固定される列を先頭にが優先です。status のような低カーディナリティ列でも、等値条件なら区間を1点に固定でき、その内側の範囲・ソートがすべて活きます。

アンチパターン

単一列 index を2本貼って満足する：idx(status) と idx(shipped_at) の2本では、BitmapAnd で合成できても整列情報が失われて ORDER BY のソートが復活します。「WHERE 2条件 + ORDER BY」が頻出のクエリなら、複合 index 1本のほうがほぼ常に優位です。

ORDER BY の方向違いを見落とす：ORDER BY shipped_at DESC が要件なのに昇順 index しかない場合、B-tree は逆走査もできるため単純なケースは助かりますが、ORDER BY a ASC, b DESC のような混在ソートは index の並びと一致せず Sort が復活します。必要なら (a ASC, b DESC) と方向を明示した index を貼ります。

実務コラム：index は「クエリの形」への投資

複合 index の設計は、個々のクエリではなく「アプリが繰り返し発行する WHERE + ORDER BY のパターン」への投資です。手順としては (1) pg_stat_statements で頻出・高負荷クエリを特定、(2) その WHERE を「等値列 / 範囲列 / ソート列」に分類、(3) 等値 → 範囲(1列) → ソートの順で列を並べた index を設計、(4) EXPLAIN ANALYZE で Sort ノードが消えたことを確認。1本の良い複合 index は、似た形のクエリ群（等値列の値違い・範囲の広さ違い）をまとめて救います。次の Q3 では、この「等値 → 範囲 → LIMIT」の走査をグループごとに繰り返す LATERAL JOIN を学びます。

QUESTION 3

LATERAL JOIN — 「顧客ごとの最新2件」を index で取り切る

LATERALグループ別Top-NLIMITIndex Scan×N

前提知識 ▼

「顧客ごとの最新N件」は実務最頻出の要件ですが、素朴に書くと難物です。ウィンドウ関数（ROW_NUMBER()）でも書けますが、対象顧客が少数なら全行スキャン + 全行ソートは過剰。LATERAL を使うと、左側の各行を引数のように受け取るサブクエリを書け、顧客1人ずつ「index で最新2件だけ拾って即終了」という最小走査が実現します。

FROM customers c
CROSS JOIN LATERAL (              -- c の各行ごとに実行されるサブクエリ
  SELECT ...
  FROM   orders
  WHERE  customer_id = c.customer_id  -- 外側の列を参照できる（LATERAL の特権）
  ORDER BY ordered_at DESC
  LIMIT  2                       -- 顧客ごとに2件で打ち切り
) o

速さの源泉：複合 index (customer_id, ordered_at DESC) があれば、各顧客のサブクエリは「等値で顧客区間に固定 → 整列済みの先頭から2行読んで終了」。注文が100万件あっても、走査は 顧客数 × 2行 で済みます。

問題 ▼

customers（3行）と orders（実体100万行、複合インデックス idx_orders_cust_date (customer_id, ordered_at DESC) あり）から、各顧客の最新2件の注文を LATERAL JOIN で取得してください。出力列は customer_id, name, order_id, ordered_at, amount、並びは customer_id 昇順・ordered_at 降順。

使用テーブル

- customers

customer_id	name
101	Sato
102	Suzuki
103	Tanaka

- orders（(customer_id, ordered_at DESC) に複合 index）

order_id	customer_id	ordered_at	amount
1	101	2026-06-01	1200
2	102	2026-06-02	800
3	101	2026-06-03	3000
4	103	2026-06-04	500
5	101	2026-06-05	900
6	102	2026-06-06	1500
7	103	2026-06-07	700
8	101	2026-06-08	2200
9	102	2026-06-09	600

期待出力 ▼

customer_id	name	order_id	ordered_at	amount
101	Sato	8	2026-06-08	2200
101	Sato	5	2026-06-05	900
102	Suzuki	9	2026-06-09	600
102	Suzuki	6	2026-06-06	1500
103	Tanaka	7	2026-06-07	700
103	Tanaka	4	2026-06-04	500

模範解答コード ▼

SELECT   c.customer_id, c.name,
         o.order_id, o.ordered_at, o.amount
FROM     customers c
CROSS JOIN LATERAL (                       -- 顧客1行ごとに評価されるサブクエリ
  SELECT order_id, ordered_at, amount
  FROM   orders
  WHERE  customer_id = c.customer_id        -- 外側の c を参照（相関）
  ORDER BY ordered_at DESC                  -- index の並びそのまま
  LIMIT  2                                  -- 2行読んだら即終了
) o
ORDER BY c.customer_id, o.ordered_at DESC;

/*
  実行順序:
  1. customers を走査                          → 3行
  2. 各顧客で idx の区間先頭から2行                     → LIMIT で即終了
  3. 3顧客分を結合                                → 6行
  4. ORDER BY customer_id, ordered_at DESC  → 最終整列
  */

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

SELECT   c.customer_id, c.name,
         o.order_id, o.ordered_at, o.amount
FROM     customers c
CROSS JOIN LATERAL (
  SELECT order_id, ordered_at, amount
  FROM   orders
  WHERE  customer_id = c.customer_id
  ORDER BY ordered_at DESC
  LIMIT  2
) o
ORDER BY c.customer_id, o.ordered_at DESC;

LEGEND ▼

データ取得・読込対象

1. 対象テーブル — 「顧客ごとに最新2件」という要件 ▼

FROM customers c / orders普通の JOIN は「条件に合う行を全部」結合しますが、今回は「顧客ごとに2件だけ」。このグループ単位の打ち切りを表現できるのが LATERAL + LIMIT です。orders は実体100万行という想定で見てください。

1 / 5

order_id	customer_id	ordered_at	amount
1	101	2026-06-01	1200
2	102	2026-06-02	800
3	101	2026-06-03	3000
4	103	2026-06-04	500
5	101	2026-06-05	900
6	102	2026-06-06	1500
7	103	2026-06-07	700
8	101	2026-06-08	2200
9	102	2026-06-09	600

orders 9行（実テーブルは100万行）

学習ポイント

LATERAL = 「行を引数に取れるサブクエリ」：通常の FROM 句サブクエリは外側の列を参照できませんが、LATERAL を付けると c.customer_id のような外側の値を内側で使えるようになります。各行ごとに ORDER BY + LIMIT を効かせられるため、「グループごとの打ち切り」を実行計画レベルで表現できるのが本質的な価値です。

性能の前提は複合 index (グループ列, 並び列)：LATERAL 自体は魔法ではなく、index がなければ「顧客ごとに Seq Scan + Sort」を N 回繰り返す最悪形になります。(customer_id, ordered_at DESC) という「等値 → 整列」設計とセットではじめて「区間先頭から LIMIT 行だけ」の最小走査になります。

JOIN LATERAL と LEFT JOIN LATERAL：注文が1件もない顧客も出力に残したい場合は LEFT JOIN LATERAL (...) o ON true を使います（注文側の列は NULL で埋まる）。CROSS JOIN LATERAL は「サブクエリが0行ならその顧客ごと消える」INNER 結合の意味になる点に注意してください。

アンチパターン

アプリ側ループで N+1 クエリにする：「顧客ごとに最新2件」をアプリのループで顧客数ぶん SELECT を発行する実装は、1回ごとのネットワーク往復が積み上がる N+1 問題の典型です。LATERAL は同じ「ごとに」のロジックを1クエリ・1往復に畳み込む、N+1 のSQL側解決策と捉えられます。

MAX(ordered_at) で自己結合して最新1件を取る：JOIN (SELECT customer_id, MAX(ordered_at) ...) 方式は、同時刻の注文が複数あると行が重複するうえ、「最新2件」へ拡張できません。最新1件でも LATERAL + LIMIT 1（または DISTINCT ON）のほうが正確で速いケースが大半です。

実務コラム：DISTINCT ON という PostgreSQL の近道

「グループごとの最新1件だけ」なら、PostgreSQL には SELECT DISTINCT ON (customer_id) ... ORDER BY customer_id, ordered_at DESC という専用構文があり、同じ複合 index で高速に動きます。使い分けの目安は、1件なら DISTINCT ON、N件なら LATERAL + LIMIT、全グループの一括ランキングならウィンドウ関数。3つとも「グループ別 Top-N」という同じ問題の道具なので、要件（件数・対象グループ数・index の有無）で選びます。次の Q4 では、集約そのものを1パスに畳み込む FILTER 句を見ます。

QUESTION 4

FILTER 句 — 1回の走査で複数の条件付き集約を畳み込む

FILTER条件付き集約HAVING1パス集計

前提知識 ▼

「決済手段ごとに、全体件数と成功件数と失敗額合計を出す」——条件の違う集約が複数並ぶレポート要件です。テーブルを条件ごとに3回スキャンして JOIN するのは最悪手。PostgreSQL の FILTER 句を使えば、1回の走査の中で集約関数ごとに対象行を選り分けられます。

-- ✗ 条件ごとにスキャンを繰り返して JOIN（3パス）
SELECT ... FROM (成功だけ集計) JOIN (失敗だけ集計) ON ...

-- ✓ FILTER：1パスの中で集約ごとに行を選別
COUNT(*) FILTER (WHERE status = 'ok')   -- この COUNT だけ ok 行を数える
SUM(amount) FILTER (WHERE status = 'ng') -- この SUM だけ ng 行を足す

WHERE / FILTER / HAVING の3層を区別する：WHERE は「集約に入れる行」を全体で絞る（集約前・index 可）。FILTER は「その集約関数1つだけの対象行」を絞る。HAVING は「集約し終わったグループ」を絞る（集約後）。基礎編の WHERE vs HAVING に、中間の第3層が加わった形です。

問題 ▼

payments テーブル（実体800万行）から決済手段（method）ごとに、全体件数 cnt・成功件数 ok_cnt（status='ok'）・失敗額合計 ng_amount（status='ng' の amount 合計、該当なしは 0） を1回の走査で集計し、件数が2以上の手段だけを method 昇順で取得してください。

使用テーブル

- payments

pay_id	method	status	amount
1	card	ok	1200
2	bank	ok	5000
3	card	ng	800
4	card	ok	2400
5	paypay	ok	600
6	bank	ng	3000
7	card	ng	500
8	bank	ok	7000

期待出力 ▼

method	cnt	ok_cnt	ng_amount
bank	3	2	3000
card	4	2	1300

模範解答コード ▼

SELECT   method,
         COUNT(*)                                  AS cnt,       -- 全行が対象
         COUNT(*)    FILTER (WHERE status = 'ok') AS ok_cnt,    -- ok 行だけ数える
         COALESCE(
           SUM(amount) FILTER (WHERE status = 'ng'), 0
         )                                          AS ng_amount  -- ng なしグループは NULL → 0 に
FROM     payments
GROUP BY method
HAVING   COUNT(*) >= 2                            -- 集約後のグループ条件は HAVING へ
ORDER BY method;

/*
  実行順序:
  1. FROM payments — 8行を1回だけ走査
  2. GROUP BY method — bank / card / paypay の3グループに分類
  3. 各グループ内で3つの集約が並走:
     COUNT(*) は全行、FILTER(ok) は ok 行のみ、FILTER(ng) は ng 行のみを集計
  4. HAVING COUNT(*) >= 2 — paypay (1件) を除外
  5. SELECT — COALESCE で ng なしグループの NULL を 0 に変換
  6. ORDER BY method — 2グループを整列
  → 結果: 2行 × 4列（テーブル走査は1パスのみ）
*/

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

SELECT   method,
         COUNT(*) AS cnt,
         COUNT(*) FILTER (WHERE status = 'ok') AS ok_cnt,
         COALESCE(SUM(amount) FILTER (WHERE status = 'ng'), 0) AS ng_amount
FROM     payments
GROUP BY method
HAVING   COUNT(*) >= 2
ORDER BY method;

LEGEND ▼

データ取得・読込対象

1. FROM payments — 走査はこの1回だけ ▼

FROM payments要件には「全体」「ok のみ」「ng のみ」という3つの異なる対象範囲が混ざっています。800万行のテーブルを3回読むか、1回で済ませるか——FILTER の出番です。

1 / 5

pay_id	method	status	amount
1	card	ok	1200
2	bank	ok	5000
3	card	ng	800
4	card	ok	2400
5	paypay	ok	600
6	bank	ng	3000
7	card	ng	500
8	bank	ok	7000

8行（実テーブルは800万行）

学習ポイント

FILTER は「集約関数のプライベート WHERE」：WHERE が全集約の共通フィルタなのに対し、FILTER は付けた集約関数1つだけに効きます。これにより「対象範囲の異なる集計」を1クエリ・1パスに同居させられます。COUNT(*) FILTER (...) は SUM(CASE WHEN ... THEN 1 ELSE 0 END) より意図が読み取りやすく、NULL の扱いも素直です。

全集約に共通の条件は WHERE に「昇格」させる：もし全集約が status IN ('ok','ng') の行しか見ないなら、その条件は FILTER に分散させず WHERE に1つ書くべきです。WHERE は集約前に行数自体を減らし index も使えるため、層が上であるほど安く効きます。「最も外側に出せる条件はどれか」を常に考えるのが集約チューニングの型です。

該当0行の SUM は 0 ではなく NULL：FILTER で対象行が1行もなかったグループの SUM は NULL を返します（COUNT は 0）。レポートでは COALESCE(..., 0) で明示的に潰すのが定石。NULL のまま後続の計算（差分・比率）に流すと、結果全体が静かに NULL 化する事故につながります。

アンチパターン

条件ごとにサブクエリを作って JOIN で束ねる：「成功集計」「失敗集計」を別サブクエリにして method で JOIN する書き方は、同じ巨大テーブルを条件の数だけスキャンするうえ、片方にしか存在しない method が INNER JOIN で消える正しさの罠も抱えます。FILTER なら1パス・全 method 保持で両方解決します。

HAVING に書ける条件を WHERE で無理に書く（その逆も）：WHERE COUNT(*) >= 2 はエラー（WHERE 時点で集約値は存在しない）、逆に HAVING status = 'ok' は GROUP BY に status を足さない限りエラーか意図不明なSQLになります。「行で決まるか、グループで決まるか」で機械的に振り分けてください。

実務コラム：ピボット集計と FILTER

FILTER の真価はピボット（クロス集計）レポートで発揮されます。「月別 × ステータス別の件数表」のような要件は、COUNT(*) FILTER (WHERE status='ok') AS ok, COUNT(*) FILTER (WHERE status='ng') AS ng, ... と列方向に並べるだけで、1パスのまま横持ちの表が完成します。BIツールに渡す前処理SQLや日次バッチの集計で、「同じテーブルを何度も読んでいないか？」と疑う癖をつけると、FILTER で畳める箇所が次々見つかるはずです。最後の Q5 では、集計やキュー処理の「対象がテーブルのごく一部」という性質を index 側に焼き込む部分インデックスを学びます。

QUESTION 5

部分インデックス — 「未処理の1%」だけを索引して小さく速く

部分indexWHERE付きindexLIMITキュー処理

前提知識 ▼

ジョブキューや注文ステータスのようなテーブルでは、検索対象は常に「未処理（pending）」のごく一部なのに、行の99%は処理済み——という偏りが生まれます。全行を索引する通常 index は、この99%のためにサイズと更新コストを払い続けるムダを抱えます。CREATE INDEX ... WHERE 条件 の部分インデックスは、条件に合う行だけを索引する小さな index です。

-- pending 行（全体の1%）だけを索引する部分 index
CREATE INDEX idx_tasks_pending
  ON tasks (created_at)
  WHERE status = 'pending';   -- ← この述語が index の「守備範囲」

使われる条件：部分 index は、クエリの WHERE が index の述語を含意するときだけ採用されます。WHERE status = 'pending' を書けば使われ、WHERE status IN ('pending', 'done') では使われません。「index の述語 ⊇ クエリの絞り込み」が成立するかをプランナが判定します。

問題 ▼

tasks テーブル（実体100万行、うち status = 'pending' は約1%）に対し、(1) pending 行だけを created_at 順に索引する部分インデックスを作成し、(2) それを使って最も古い pending タスク3件を取得してください。出力列は task_id, created_at, title。

使用テーブル

- tasks（100万行中 pending は約1%）

task_id	status	created_at	title
1	done	2026-05-01	請求書作成
2	pending	2026-05-03	在庫棚卸
3	done	2026-05-04	月次レポート
4	pending	2026-05-06	契約書レビュー
5	canceled	2026-05-08	旧サイト改修
6	pending	2026-05-10	監査資料準備
7	done	2026-05-12	採用面接調整
8	pending	2026-05-13	価格改定通知

期待出力 ▼

task_id	created_at	title
2	2026-05-03	在庫棚卸
4	2026-05-06	契約書レビュー
6	2026-05-10	監査資料準備

模範解答コード ▼

CREATE INDEX idx_tasks_pending  -- (1) pending 行だけを索引する部分インデックス
  ON tasks (created_at)
  WHERE status = 'pending';     -- 索引対象は全体の約1%だけ

-- (2) 最も古い pending タスク3件
SELECT   task_id, created_at, title
FROM     tasks
WHERE    status = 'pending'        -- index の述語と一致 → 部分 index が採用される
ORDER BY created_at                 -- index の並びそのまま
LIMIT    3;                         -- 先頭3エントリで走査終了

/*
  実行順序:
  1. WHERE が index 述語を満たす  → idx_tasks_pending を採用
  2. index の先頭から走査         → 最古の pending から
  3. LIMIT 3 で走査終了         → 4件目以降は未走査
  4. テーブル本体から列を取得          → 3行ぶん
  */

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

CREATE INDEX idx_tasks_pending
  ON tasks (created_at)
  WHERE status = 'pending';

SELECT   task_id, created_at, title
FROM     tasks
WHERE    status = 'pending'
ORDER BY created_at
LIMIT    3;

LEGEND ▼

データ取得・読込対象

除外・非表示データ

1. 対象テーブル — 検索するのは常に pending の1%だけ ▼

FROM tasks（100万行）キュー型テーブルの典型的な偏りです：行は溜まり続けるが、クエリが見たいのは常に「未処理」の一部だけ。done / canceled の99万行は検索対象になることがほぼありません。

1 / 5

task_id	status	created_at	title
1	done	2026-05-01	請求書作成
2	pending	2026-05-03	在庫棚卸
3	done	2026-05-04	月次レポート
4	pending	2026-05-06	契約書レビュー
5	canceled	2026-05-08	旧サイト改修
6	pending	2026-05-10	監査資料準備
7	done	2026-05-12	採用面接調整
8	pending	2026-05-13	価格改定通知

8行（実テーブル100万行 / pending 約1万行）

学習ポイント

部分 index は「述語の含意」で採用が決まる：プランナは「クエリの WHERE を満たす行は、必ず index の述語も満たすか」を機械的に判定します。status = 'pending' は OK、status IN ('pending','done') やバインド変数 status = $1（値が実行時まで不明）は NG。固定リテラルで書ける条件に絞って述語を設計するのがコツです。

小ささは速さに直結する：部分 index の利点は走査の速さだけではありません。(1) サイズが小さい → ほぼ常時キャッシュに乗る、(2) 述語外の行の更新では index 更新が発生しない → 書込みが軽い、(3) B-tree の深さが浅い → 探索が短い。「読みも書きも軽くなる」のは、index 系チューニングでは珍しい性質です。

部分 UNIQUE という応用：部分 index は UNIQUE 制約とも組めます。CREATE UNIQUE INDEX ... ON users (email) WHERE deleted_at IS NULL とすれば、「論理削除されていないユーザーの中でだけメールアドレス一意」という、通常の UNIQUE 制約では表現できない業務ルールを実装できます。実務での部分 index の代表的な使い所です。

アンチパターン

述語とクエリの条件がズレたまま気づかない：アプリ改修で検索条件が status = 'pending' から status IN ('pending','retrying') に変わると、部分 index は静かに使われなくなり Seq Scan に退化します。部分 index を貼ったら、その述語をクエリ側の契約（コメントやテスト）として明文化し、EXPLAIN の定期確認に含めてください。

頻繁に値が変わる条件で部分 index を作る：WHERE updated_at > '2026-01-01' のような時間とともに意味が変わる述語は、作った瞬間から守備範囲が実態とズレていきます。部分 index の述語は「status のような離散的で安定した状態」に限定するのが安全です。

実務コラム：応用編の総まとめ — 「形」を index に寄せる5原則

応用編この5問を貫くテーマは「クエリとデータの偏りの『形』を、index が読める形に揃える」でした。1. 期間条件は半開区間で列を素のまま渡す（Q1）、2. 複合 index は等値 → 範囲 → ソートの列順で設計する（Q2）、3. 「グループごとに N 件」は LATERAL + LIMIT で区間先頭だけ読む（Q3）、4. 対象範囲の違う集計は FILTER で1パスに畳む（Q4）、5. 固定の絞り込みは部分 index に焼き込む（Q5）。基礎編2の5原則（型を揃える / 前方一致 / OR 分解 / WHERE と HAVING / カバリング）と合わせれば、SELECT 文チューニングの判断基準は「EXPLAIN を見て、どの原則からズレているかを探す」作業に整理できます。実データでは必ず EXPLAIN (ANALYZE, BUFFERS) で仮説を検証する習慣まで含めて、応用編の完成です。