こんにちは！データベースのパフォーマンスチューニングの世界へようこそ。
日々PostgreSQLを触っていると、「あれ、このクエリ、なんでこんなに遅いんだろう？」と頭を抱える瞬間に出会いませんか？インデックスはちゃんと貼ったはずなのに、なぜかフルスキャンが走ってしまったり……。
そんなとき、多くのエンジニアが暗闇の中で手探りするように `EXPLAIN ANALYZE` のテキスト出力を眺めては、溜息をついています。
ですが、安心してください。あなたが普段使っている pgAdmin 4 には、その苦悩を一瞬で解消してくれる強力な武器が標準装備されています。それが 「グラフィカル実行計画ビジュアライザ」 です。
今回は、pgAdminのQuery Toolを使って実行計画を視覚的に読み解き、データベースのボトルネックを外科手術のように正確に特定する極意を、優しく丁寧にお伝えします。これをマスターすれば、毎日のパフォーマンスチューニングが劇的に楽しく、そして楽になりますよ！
—
1. 実行計画（EXPLAIN ANALYZE）ってなに？ なぜpgAdminのビジュアライザを使うべきなの？
まず、「実行計画」について軽くおさらいしておきましょう。
PostgreSQL（正確にはオプティマイザ）は、私たちが書いたSQL（「何が欲しいか」）を、「どうやってデータを取ってくるのが一番速いか」という手順書（実行計画）に翻訳してから実行します。
- `EXPLAIN` ：その手順書を見るコマンド。
- `EXPLAIN ANALYZE` ：実際にクエリを実行し、予測コストと「実際の実行時間・行数」を突き合わせるコマンド。
テキスト版の `EXPLAIN ANALYZE` は、以下のようにツリー構造のテキストが出力されます。
-> Seq Scan on users (cost=0.00..183.00 rows=10000 width=36) (actual time=0.015..1.523 rows=10000 loops=1)
……正直、慣れていないと読む気が失退しますよね。どのノードが最も時間を食っているのか、全体像を把握するのに脳内メモリを大量消費します。
そこで登場するのが pgAdmin 4 のグラフィカル実行計画 です。テキストの海を、直感的な「フローチャート（ノードのツリー）」に変換し、どこが重いのかを色で教えてくれる。使わない手はありません。
—
2. 基礎セットアップ：pgAdminで実行計画をビジュアル表示する手順
百聞は一見にしかず。まずは実際に動かしてみましょう。準備はとても簡単です。
ステップ1：Query Toolを開く
pgAdminのオブジェクトブラウザから対象のデータベースを選択し、上部メニューの 「Tools」 > 「Query Tool」 を開きます（あるいは、稲妻マークのアイコンをクリック）。
ステップ2：動作確認用のテーブルとデータを作る
以下のSQLをQuery Toolに貼り付けて実行し、テスト用のデータを作ってみてください。
— テスト用のユーザーテーブルを作成
CREATE TABLE users (
id SERIAL PRIMARY KEY,
name VARCHAR(50),
status VARCHAR(20),
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
— ダミーデータを10万件挿入（少し重い処理の再現用）
INSERT INTO users (name, status)
SELECT
‘User_’ || generate_series,
CASE WHEN generate_series % 2 = 0 THEN ‘active’ ELSE ‘inactive’ END
FROM generate_series(1, 100000);
— インデックスを作成（最初はstatusにはインデックスを貼らないでおく）
ステップ3：あえて「遅いクエリ」をEXPLAIN ANALYZEする
インデックスがない状態であえて検索をかけてみます。Query Toolに以下のように入力してください。
> ⚠️ 超重要注意：
> `EXPLAIN ANALYZE` をつけると、実際にクエリが実行されます。本番環境の更新系（INSERT / UPDATE / DELETE）のクエリにうっかり `ANALYZE` をつけると、データが書き換わってしまうので、基本は `SELECT` で検証するか、本番では `ANALYZE` なしで `EXPLAIN` のみを使うのが鉄則です。
— statusが ‘active’ のユーザーを検索
EXPLAIN ANALYZE
SELECT FROM users WHERE status = ‘active’;
SQLを入力したら、実行ボタン（通常はF5キー、または緑の再生ボタンの隣にある「EXPLAIN ANALYZE」アイコン（虫眼鏡と時計のマーク））をクリックします。
—
3. 視覚的読み解き方：カラーインジケータとボトルネックの特定
実行すると、画面下部のパネルに 「Graphical Explain」 というタブが現れます。ここをクリックしてください。
色鮮やかなブロック（ノード）がツリー状に並んでいますね。ここからが本番です。
① カラーインジケータ（色の意味）を理解する
pgAdminのグラフィカル実行計画では、各ノードに「コスト」や「実行時間」に応じたカラーバリエーションが適用されます。
- 青・緑系：コストや時間が低く、健康な状態。
- 黄〜赤系：コストや時間が非常に高く、ボトルネック（悪者）の可能性大！
今回のクエリでは、一番上のルートノードやスキャンノードが赤っぽく光っているはずです。
② ノードの詳細情報を覗き見する
怪しいノード（ブロック）にマウスオーバーするか、クリックしてみましょう。ポップアップで詳細なメトリクスが表示されます。ここで見るべき重要な指標は以下の3つです。
1. Node Type（ノードの種類）：後述する「Seq Scan」や「Index Scan」など、どうやってデータにアクセスしたか。
2. Total Cost（総コスト）：オプティマイザが算出した内部的な負荷の目安。
3. Actual Total Time（実時間）：そのノードの処理に実際に何ミリ秒かかったか。
4. Actual Rows（実行数）：実際に何件のデータを処理したか。
ここで、先ほどのクエリのノードを見ると、「Seq Scan (Sequential Scan)」 という文字があり、Actual Rows が `50000`（5万件）になっています。
これが「フルテーブルスキャン（全件走査）」です。10万件のテーブルから条件に合う5万件を探すために、PostgreSQLはディスクの最初から最後まですべてを舐め回すように読み込んでいたのです。そりゃあ遅いはずですね。
—
4. 遅いクエリを高速化するチューニングの極意
原因（Seq Scanによる大量データの読み込み）がわかったので、処置を施します。
処置：インデックスの作成
検索条件に使われている `status` カラムにインデックスを付与してみましょう。
— statusカラムにインデックスを作成
CREATE INDEX idx_users_status ON users(status);
インデックスを作ったら、もう一度同じ `EXPLAIN ANALYZE` を実行してみます。
EXPLAIN ANALYZE
SELECT FROM users WHERE status = ‘active’;
結果はどう変わったか？
Graphical Explainタブを再度見てください。
1. Node Type が 「Bitmap Heap Scan」 または 「Index Scan」 に変わっています。
2. ノードの色が、青や緑の「安全色」に変わっているはずです。
3. Actual Total Time が劇的に短縮されているのを確認できます。
これが、pgAdminのビジュアライザを使ったボトルネック特定の王道パターンです。
—
5. 現場で役立つ！見逃してはいけない危険なサイン（アンチパターン）
最後に、実務の現場でpgAdminの実行計画を見たときに「おや？」と気づくべき、代表的な危険なサインをいくつか紹介します。
1. 予想行数（Rows）と実行数（Actual Rows）の絶望的な乖離
ノードにマウスオーバーすると、「Rows: 10（予測）」に対して「Actual Rows: 100000（実際）」のように、数字がかけ離れていることがあります。
これは、データベースの統計情報が古くなっている証拠です。
- 対策：`ANALYZE users;` を実行して統計情報を最新化し、オプティマイザに正しい判断材料を与えましょう。
2. Nested Loop と大量のループ回数
結合（JOIN）を行うクエリで `Nested Loop` が使われており、その内部ループの回数（Loops）が何十万回にも膨れ上がっている場合、CPUに大きな負荷がかかります。
- 対策：結合条件のインデックス見直しや、ハッシュ結合（Hash Join）を促すようなクエリ構造へのリファクタリングを検討します。
3. ソート処理のメモリ溢れ（External Merge Sort）
Order By句やGroup By句があるクエリで、ノードに `Sort Method: external merge` と書かれている場合、メモリ（work_mem）に収まらきらず、一時的にディスク（ストレージ）に書き出してソートを行っています。これは非常に低速です。
- 対策：`work_mem` の設定値を増やすか、不要なソートを削る、インデックスによる順序維持を活用します。
—
まとめ
いかがでしたでしょうか？
pgAdmin 4 のグラフィカル実行計画（EXPLAIN ANALYZE ビジュアライザ）を使えば、難解なSQLの内部挙動がまるでパズルのようにクリアに見えてきます。
1. Query Tool で `EXPLAIN ANALYZE` を実行する（※SELECT文でね！）
2. Graphical Explain タブを開き、赤く光る重いノードを見つける。
3. ノードのホバー情報から 「Seq Scan」や「コスト・実時間」 を確認し、ボトルネックを特定する。
4. インデックスや統計情報の更新で、緑色の快適な世界へ導く。
このサイクルを習慣にするだけで、あなたのデータベースチューニング能力は圧倒的に跳ね上がります。毎日の開発やトラブルシューティングが、きっとグッと楽になりますよ。
それでは、快適なデータベースライフを！