クエリ最適化とパフォーマンス

🔄 前回のおさらい: レッスン4では、AIで乱雑なデータをクリーニングしました——プロファイリング、標準化、重複排除、検証。今回は、クリーンなデータに対するクエリが高速に動くことを確認します。

クエリが遅くなるとき

低速クエリは通常、自ら存在を主張します：ダッシュボードのロードに30秒、レポートのタイムアウト、ユーザーを待たせるAPIエンドポイント。原因はデータベース自体ではなく、ほとんどの場合クエリかインデックスの欠落です。

AIは実行計画を読み、人間なら何年もの経験を要するパターンを見つけられるため、最適化に非常に優れています。

EXPLAIN ANALYZEでの診断

EXPLAIN ANALYZEコマンドが診断ツールです。出力は暗号的に見えますが、AIに貼り付けると即座に分析してくれます：最大のパフォーマンスボトルネック、不要なシーケンシャルスキャン、行推定の精度、必要なインデックス、クエリの書き直し提案。

✅ 確認クイズ: 実行計画でデータベースの行推定が「大幅にずれている」ことが重要な理由は？（クエリプランナーは推定行数に基づいて戦略を選ぶ。100行と推定して実際は100,000行なら、ネステッドループJOIN（小さなセットに効率的）を選ぶかもしれないが、ハッシュJOIN（大きなセットに効率的）のほうが劇的に速い。不正確な推定はテーブル統計が古いことを意味する——テーブルにANALYZEを実行すれば修正される。）

戦略的インデックス設計

インデックスの重要原則：

• 複合インデックス： 等値カラムを先に、範囲カラムを後に。(customer_id, order_date) がクエリ#1に効く——(order_date, customer_id)ではない。
• パーシャルインデックス： pendingの注文だけクエリするなら、CREATE INDEX ON orders (created_at) WHERE status = 'pending'がすべてのステータスのインデックスより小さく速い。
• 過度のインデックスを避ける： 各インデックスがINSERT/UPDATEを遅くする。毎秒10,000書き込みのテーブルに5つのインデックスを追加すると深刻なオーバーヘッド。

よくある最適化パターン

*SELECT を特定カラムに置換：

-- 遅い（ディスクからすべてのカラムを読む）
SELECT * FROM orders WHERE customer_id = 123;

-- 速い（必要なカラムのみ読み、カバリングインデックスを活用可能）
SELECT id, total, order_date FROM orders WHERE customer_id = 123;

フィルタリングをHAVINGからWHEREへ：

-- 遅い（すべての行をグループ化してからフィルタ）
SELECT customer_id, SUM(total) FROM orders
GROUP BY customer_id HAVING customer_id IN (1, 2, 3);

-- 速い（まずフィルタしてから少ない行をグループ化）
SELECT customer_id, SUM(total) FROM orders
WHERE customer_id IN (1, 2, 3) GROUP BY customer_id;

大きなサブクエリにINの代わりにEXISTS：

-- サブクエリ結果が多いと遅い
SELECT * FROM customers WHERE id IN (SELECT customer_id FROM orders);

-- 速い（行ごとに最初のマッチで停止）
SELECT * FROM customers c WHERE EXISTS (
    SELECT 1 FROM orders o WHERE o.customer_id = c.id
);

✅ 確認クイズ: サブクエリが多くの行を返す場合、EXISTSがINより速い理由は？（INはサブクエリ結果全体（数百万の値の可能性）を実体化し、各外部行と照合。EXISTSは最初のマッチで停止——顧客に注文が1つ見つかれば次へ。「この顧客に注文があるか？」の質問にEXISTSは行ごとに最小限の作業、INは最大限の作業を行う。）

まとめ

• EXPLAIN ANALYZEが診断ツール——実行計画をAIに貼り付ければ即座にエキスパートレベルの分析が得られる
• 戦略的インデックスはクエリパターン、カラムカーディナリティ、書き込みオーバーヘッドを考慮——すべてのカラムにインデックスが必要なわけではない
• 複合インデックスはクエリパターンに一致させる：等値カラム先、範囲カラム後
• よくあるクイックウィン：SELECT *の置換、WHERE句へのフィルタ移動、大きなサブクエリでINの代わりにEXISTS
• 古いテーブル統計がクエリプランナーの誤った戦略選択の原因——定期的にANALYZEを実行

次のレッスン

次は「レポートとダッシュボード」——最適化されたクエリを使ってビジネスインテリジェンスを構築する方法を学びます。