EXPLAIN は PostgreSQL のクエリ実行計画を表示します — クエリがどのように実行されるか（どのスキャン、結合、インデックスを使用するか）を示します。EXPLAIN ANALYZE は実際にクエリを実行し、実際のタイミングと行数を表示します。これらは遅いクエリを診断するための主要なツールです。
EXPLAIN — 計画（実行なし）
sql
EXPLAIN orders customer_id ;
EXPLAIN は PostgreSQL のクエリ実行計画を表示します — クエリがどのように実行されるか（どのスキャン、結合、インデックスを使用するか）を示します。EXPLAIN ANALYZE は実際にクエリを実行し、実際のタイミングと行数を表示します。これらは遅いクエリを診断するための主要なツールです。
EXPLAIN orders customer_id ;
EXPLAIN ANALYZE SELECT * FROM orders WHERE customer_id = 5;
-- ACTUALLY runs it → shows REAL time, ACTUAL rows, and where time was spent
EXPLAIN (ANALYZE, BUFFERS) SELECT ...; -- also shows buffer/cache usage
EXPLAIN ANALYZE はより有用です。なぜなら、実際のパフォーマンス（実際のタイミング、実際の行数）を表示するため、推定値ではなく、クエリが本当に時間を費やす場所を明らかにするからです。
SCAN TYPES (most important):
Seq Scan → FULL TABLE SCAN (reads every row) — slow on big tables, often the problem
Index Scan → uses an index to find rows — fast
Index Only Scan → reads only the index (doesn't touch the table) — fastest
Bitmap Scan → for combining indexes / many matches
WATCH FOR:
✗ Seq Scan on a large table being filtered → likely a MISSING INDEX
✗ Estimated rows VERY different from actual rows → outdated statistics (run ANALYZE)
✗ Expensive joins, sorts spilling to disk ("external merge")
✗ The node with the highest actual time = the bottleneck
EXPLAIN ANALYZE SELECT * FROM orders WHERE customer_id = 5;
-- "Seq Scan on orders ... actual time=120ms" → a full scan, slow
CREATE INDEX idx_orders_customer ON orders(customer_id);
EXPLAIN ANALYZE SELECT * FROM orders WHERE customer_id = 5;
-- "Index Scan using idx_orders_customer ... actual time=0.05ms" → fixed!
EXPLAIN と EXPLAIN ANALYZE は PostgreSQL で遅いクエリを診断し最適化するための本質的で主要なツールです — クエリパフォーマンスはアプリケーションにとって重要であり、これらのツールはクエリが遅い理由を理解し、修正を検証する方法です。そのため、これらをマスターすることはデータベースパフォーマンス作業における重要なシニアレベルの知識です。
基本的な価値は実行計画への可視性です。クエリが遅い理由を推測する代わりに、EXPLAIN ANALYZE（クエリを実行し、実際のタイミングと行数を表示）は PostgreSQL がそれをどのように実行し、時間がどこに費やされているかを正確に明らかにします。
最も重要なことは、スキャンタイプを認識することです — 特に大きなフィルター済みテーブル上の**Seq Scan（全表スキャン）を特定することです。これは通常、インデックスが不足している（最も一般的で影響の大きいクエリパフォーマンス問題）を示すのに対し、高速なIndex Scan**と比較します。
計画を読む方法を理解すること（スキャンタイプ、推定行数と実際の行数を比較して古い統計を検出、最も費用の高いノードをボトルネックとして特定、ディスクスピル ソートの監視）はクエリ最適化のための重要なスキルです。
診断ワークフロー — EXPLAIN ANALYZE を実行し、ボトルネック（多くの場合、Seq Scan）を特定し、修正を適用し（通常、インデックスを追加）、検証するために再実行する — はクエリ最適化の標準的で測定駆動型のアプローチです。
遅いクエリは不十分なデータベースパフォーマンスの主な原因であり、EXPLAIN/EXPLAIN ANALYZE はそれらを診断するための唯一のツール（不足しているインデックス、悪いプラン、ボトルネックを明らかにする）であり、最適化を検証するため、これらをマスターすることは PostgreSQL パフォーマンスの重要で高価値な知識です — これは推測するのではなく、遅いクエリを体系的に発見し修正する方法であり、パフォーマンスの高いデータベースにとって重要なスキルであり、データベース最適化作業の一般的なトピックです。