こんにちは、Anti-Patternの塚本です。
\n以前、サイロ化していたデータベースを共通のプール（統合基盤）へ移行するプロジェクトを担当した。
1つの基盤に集約すれば、当然そのぶん1つのテーブルが抱えるデータ量は一気に増える。データは繋がって扱いやすくなる一方で、それまで問題なく動いていたクエリが、量に負けて遅くなっていった。
\n当時、いまのようなAIは無かった。だから、やることは全部手作業だった。
\nEXPLAIN ANALYZE を取って実行計画を読むSeq Scan が出ているか、Nested Loop が何回まわっているかを目で追う一つ直しては計画を取り、また直しては計画を取る。地味で、時間のかかる作業だった。
\nそれでも、遅いクエリが速くなっていく手応えは確かにあった。
当時を振り返るために、同じような状況を小さく作って検証してみた。
\n遅いSQLには、当時よく見た「あるある」を意図的に仕込んだ。
\n| 仕込んだアンチパターン | \n直し方 | \n
|---|---|
| 相関サブクエリで行ごとに集計 | \n事前集約したサブクエリと JOIN | \n
無駄な結合で行が膨張 → DISTINCT でごまかす | \n事前集約して重複を出さない | \n
IN (サブクエリ) / NOT IN (サブクエリ) | \nJOIN / NOT EXISTS（アンチジョイン） | \n
テーブルをまたぐ OR 条件 | \nOR + EXISTS に整理 | \n
| 1行しか返らないテーブルの不要な結合 | \n削除 | \n
やりたいことは「そのテナント内で、status=active かつ paid の注文があり、
\ncancelled の注文が無く、（2025-06-01より後に作成 or pending の注文を持つ）ユーザーを、
\npaid合計金額の降順で並べる」というもの。それを、あえて悪い書き方でやる。
SELECT DISTINCT -- ← 膨張を隠すための DISTINCT\n u.user_id,\n u.email,\n (SELECT COALESCE(SUM(o2.amount), 0) -- ← 相関サブクエリ（行ごとに集計）\n FROM orders o2\n WHERE o2.user_id = u.user_id\n AND o2.status = 'paid') AS total_paid\nFROM users u\nJOIN tenants t ON t.tenant_id = u.tenant_id -- ← 1行しか返らないのに結合（不要）\nJOIN orders o ON o.user_id = u.user_id -- ← fan-out（行が2倍に膨張）\nWHERE u.status = 'active'\n AND u.user_id IN ( -- ← IN (サブクエリ)\n SELECT o3.user_id FROM orders o3 WHERE o3.status = 'paid')\n AND u.user_id NOT IN ( -- ← NOT IN (サブクエリ)\n SELECT o4.user_id FROM orders o4 WHERE o4.status = 'cancelled')\n AND ( u.created_at > DATE '2025-06-01' -- ← テーブルをまたぐ OR\n OR u.user_id IN (\n SELECT o5.user_id FROM orders o5 WHERE o5.status = 'pending') )\nORDER BY total_paid DESC, u.user_id;\n同じ結果を返しつつ、悪い構造を潰した版がこちら。
\nSELECT\n u.user_id,\n u.email,\n COALESCE(pa.total_paid, 0) AS total_paid\nFROM users u\nJOIN ( -- ★相関サブクエリ → 事前集約に\n SELECT user_id, SUM(amount) AS total_paid -- paid合計を「一度だけ」計算\n FROM orders\n WHERE status = 'paid'\n GROUP BY user_id\n) pa ON pa.user_id = u.user_id -- INNER JOIN が「paid が有る」= 旧 IN を兼ねる\nWHERE u.status = 'active'\n AND NOT EXISTS ( -- ★NOT IN → NOT EXISTS（アンチジョイン）\n SELECT 1 FROM orders oc\n WHERE oc.user_id = u.user_id AND oc.status = 'cancelled')\n AND ( u.created_at > DATE '2025-06-01' -- ★OR は EXISTS で整理\n OR EXISTS (\n SELECT 1 FROM orders op\n WHERE op.user_id = u.user_id AND op.status = 'pending') )\nORDER BY total_paid DESC, u.user_id;\n-- 事前集約で重複が出ないので DISTINCT も不要／不要な tenants 結合も削除\n変更点を対応づけると、こうなる。
\n| 改善前 | \n改善後 | \n効果 | \n
|---|---|---|
(SELECT SUM ...) 相関サブクエリ | \nGROUP BY で事前集約して JOIN | \n行ごとの全走査（232回）→ 1回に | \n
JOIN orders o ＋ DISTINCT | \n削除（膨張しないので不要） | \nfan-out（232行）が消える | \n
user_id IN (SELECT ...) | \n事前集約サブクエリとの INNER JOIN に吸収 | \n半結合を1つに統合 | \n
NOT IN (SELECT ...) | \nNOT EXISTS | \nAnti Join になり効率化＋NULL安全 | \n
JOIN tenants t | \n削除 | \n無駄な結合を除去 | \n
そして、改善を「インデックス追加」と「SQLリライト」の2系統に切り分けて計測した。
\n| パターン | \n実行時間 | \n
|---|---|
| ① ベースライン（インデックス無し・遅いSQL） | \n102.9 ms | \n
| ② インデックスのみ追加（遅いSQLのまま） | \n2.0 ms | \n
| ③ SQLリライト＋インデックス（最終形） | \n1.1 ms | \n
実行計画の中身もはっきり変わった。
\nSeq Scan が何度も走り、Nested Loop が行ごとに繰り返されるSeq Scan が Index Scan / Bitmap Heap Scan に。ただし相関・膨張の構造そのものは残るHash Join ＋ 事前集約に置き換わる。約96倍速くなった……当時、私が何時間もかけて手で辿り着いた場所に、いまなら数分で着く。
\n正直、これを見たときは少し複雑な気持ちになった。
「約96倍」と言われても、ピンと来ないと思う。
\nなので、実際に取得した実行計画（EXPLAIN (ANALYZE, BUFFERS)）の本物を貼る。
\nまずは①ベースライン。長いので、遅さの犯人まわりを抜粋した。
Unique (cost=2172.60..2172.63 rows=3 width=56)\n (actual time=102.742..102.784 rows=116 loops=1) -- 見積り rows=3 / 実際 116\n Buffers: shared hit=18976 -- 合計 約19,000 ブロックに触れている\n -> Sort ...\n -> Hash Join (... rows=3 ...) (actual ... rows=232 loops=1) -- fan-out で 232 行に膨張\n Hash Cond: (o.user_id = u.user_id)\n -> Seq Scan on orders o (actual ... rows=1000 loops=1) -- 無駄な結合相手を全走査\n Rows Removed by Filter: 9000\n -> Hash -> Nested Loop -> Nested Loop ...\n -> Seq Scan on orders o3 (paid 抽出) Rows Removed by Filter: 9333\n SubPlan 2 -- NOT IN (cancelled)\n -> Seq Scan on orders o4 Rows Removed by Filter: 9833\n SubPlan 3 -- OR IN (pending)\n -> Seq Scan on orders o5 Rows Removed by Filter: 9834\n SubPlan 1 -- ★相関サブクエリ（total_paid を行ごとに合計）\n -> Aggregate (actual time=0.421..0.421 rows=1 loops=232) -- 232回くり返す\n Buffers: shared hit=17168 -- ★全体の約90%\n -> Seq Scan on orders o2 (actual ... rows=1 loops=232)\n Filter: (o2.user_id = u.user_id AND o2.status='paid' ...)\n Rows Removed by Filter: 9999 -- 毎回1万件を走査して1件だけ残す\n Planning Time: 0.596 ms\n Execution Time: 102.878 ms\n1. 犯人は「相関サブクエリ」だった（SubPlan 1）
\ntotal_paid を「1行ごとに SELECT SUM(...) FROM orders WHERE user_id = u.user_id」で
\n計算していた。その結果が loops=232 ── 232回もorders全体を走査している。
\nRows Removed by Filter: 9999 が象徴的で、毎回1万件読んで9,999件を捨て、欲しいのは1件。
\nBuffers: shared hit=17168 は、このSubPlan 1だけで全体（18,976）の約90%のブロック読みを
\n占めていることを意味する。遅さの9割はここにあった。
2. Seq Scan が乱れ打ち
\norders に対して o（不要な結合）・o3（paid抽出）・o4（NOT IN）・o5（OR）・o2（相関）と、
\n同じ1万件のテーブルを何度も頭から全走査している。インデックスが無いので当然こうなる。
3. DISTINCT が"膨張"を隠していた
\n最上段は rows=116 なのに、途中の Hash Join は rows=232。
\n不要な JOIN orders o でユーザーあたり2件に膨らみ、それを Unique（＝DISTINCT）で
\n半分に潰していた。"とりあえずDISTINCT"は、たいてい設計の綻びを覆い隠している。
4. 見積りが外れている
\nプランナの見積りは rows=3、実際は rows=232 / 116。
\n統計と実データが乖離していると、プランナは誤った戦略を選びやすい。
② インデックスのみ（遅いSQLはそのまま、tenant_id先頭の複合インデックスを追加）
Execution Time: 2.006 ms -- 102.9ms → 2.0ms\n Buffers: shared hit=2885 read=9 -- 18,976 → 2,894 ブロック\n SubPlan 1\n -> Index Scan using ix_orders_tenant_user_status ... loops=232\n Buffers: shared hit=762 -- 17,168 → 762（約22分の1）\nSeq Scan が Index Scan / Bitmap Heap Scan に変わり、読むブロック数が激減した。
\nただし SubPlan 1 の loops=232（相関サブクエリ）と fan-out の構造は残ったまま。
\nインデックスは「同じ悪い構造を、速く実行する」だけで、構造は直していない。
③ SQLリライト＋インデックス（相関サブクエリを事前集約に、NOT INをNOT EXISTSに）
Execution Time: 1.075 ms\n Buffers: shared hit=595 read=3 -- さらに 595 ブロックへ\n -> Nested Loop Anti Join -- NOT EXISTS が「アンチジョイン」になった\n -> Hash Join -- 相関サブクエリ → 事前集約との Hash Join\n -> HashAggregate (paid を user 単位で1回だけ集計) rows=500\nSubPlan 1（相関サブクエリ）が消え、ordersのpaid集計は一度だけ行われてHash Joinで
\n結ばれる。NOT INはNested Loop Anti Joinに化けた。DISTINCTも不要になった（膨張が無い）。
| \n | ① baseline | \n② index only | \n③ rewrite + index | \n
|---|---|---|---|
| Execution Time | \n102.878 ms | \n2.006 ms | \n1.075 ms | \n
| 触れたブロック数 (Buffers) | \n18,976 | \n2,894 | \n598 | \n
orders への Seq Scan | \n5回 | \n0回 | \n0回 | \n
相関サブクエリ SubPlan 1 | \nあり (loops=232) | \nあり (loops=232) | \n無し | \n
DISTINCT(Unique) | \n必要 | \n必要 | \n不要 | \n
つまり、インデックスは「実行を速くする」、SQLリライトは「仕事量そのものを減らす」。
\n効くレイヤーが違う。当時の私が手作業でやっていたのは、まさにこの両方だった。
ここで大事なことを一つ。過去には戻れない。
\n「あの頃AIがあれば、あんなに時間をかけずに済んだのに」と思っても、
\nタイムマシンがあるわけではない。あの数百時間は返ってこない。
だから、その事実を嘆くよりも、これからどう使うかに頭を切り替えたい。
\n教訓は、たぶんこうだ。
\n\n知識が乏しいこと、時間がかかりそうなことは、まずAIに相談したほうがいい。
\n
実行計画の読み方を一から調べる時間、アンチパターンの直し方を思い出す時間、
\n「この結合、本当に要る？」を一つずつ検証する時間 ──
\nそういう**"調べれば分かるが、地味に重い"作業**こそ、AIが最も得意とするところだ。
ここが、今回いちばん言いたいことだ。
\nAIは一瞬でチューニング案を出す。インデックスを提案し、SQLを書き換え、
\n「これで速くなります」と言う。でも、その答えが本当に正しいかは別問題だ。
tenant_id = ...）に本当に効くのか？Nested Loop が消えたのは偶然か、それとも構造を直したからか？こういう**「AIの出力を疑い、検証し、評価する」**という営みは、
\nあの手作業の経験があったからこそできる。
昔サイロと格闘した時間は、タイムマシンでは取り戻せない。
\nでも、その経験は 「AIの答えを鵜呑みにしない目」 として、いまも効いている。
\nこれは決して無駄ではなかった、と思える。
タイムマシンは無い。けれど、過去の苦労は、未来の判断力になる。
\n