PostgreSQLインデックス最適化の現場手順:遅いクエリを再現・診断・改善する実践プレイブック
PostgreSQLインデックス最適化の現場手順:遅いクエリを再現・診断・改善する実践プレイブック 「CPUは余っているのに画面が遅い」「特定時間帯だけ API が詰まる」。この手の問題の多くは、アプリではなく SQL の実行計画に原因があります。特に PostgreSQL では、インデックス設計と統計情報の状態が性能をほぼ決めます。 本記事では、実務で使う手順に沿って、遅延クエリの改善を再現可能な形で解説します。単なる理論紹介ではなく、調査順序、判断基準、リリース時の注意点まで含めてまとめます。 まず守るべき3原則 推測でインデックスを作らない 体感で追加すると write 性能とストレージが悪化します。必ず実行計画を見てから判断します。 改善前後を数値で比較する P95、rows、shared read blocks を記録し、効果を証明します。 本番反映は CONCURRENTLY を基本にする テーブルロックで事故らないため、CREATE INDEX CONCURRENTLY を優先します。 ケース設定:注文一覧APIが遅い 次のクエリが遅いとします。 1 2 3 4 5 6 7 SELECT id, user_id, status, total_amount, created_at FROM orders WHERE tenant_id = $1 AND status IN ('paid', 'shipped') AND created_at >= NOW() - INTERVAL '30 days' ORDER BY created_at DESC LIMIT 50; データ量は orders 1.2億件、1テナントあたり数百万件。現象は「特定テナントだけ 3〜6 秒」です。 ...