【入門編】 EXPLAIN BUFFERS – PostgreSQL

こんにちは！データベースエンジニアとして日々PostgreSQLと格闘していると、時々こんな相談を受けるんです。

「なんだか最近、アプリの動きがモタつく気がするんです。コードは間違っていないはずなのに、どうしてでしょう？」

そんなとき、僕が真っ先に使うのが『EXPLAIN BUFFERS』という機能です。名前だけ聞くとちょっと難しそうですよね。でも、実はこれ、データベースが「どこで手間取っているか」を教えてくれる、すごく優秀な名探偵なんですよ。

今日は、専門用語を抜きにして、この「魔法のコマンド」が何を教えてくれるのか、一緒に見ていきましょう。

—

データベースを「巨大な図書館」だと想像してみてください。あなたが知りたいデータは、その図書館の中にある「本」に書かれています。

通常、PostgreSQLはデータを探すとき、こんな手順を踏みます。

1. まずは手元（メモリ）を確認： さっき読んだ本が机の上に置かれていないかな？（これを「ヒット」と呼びます）
2. なければ倉庫（ディスク）へ： 机になければ、わざわざ遠くの倉庫まで取りに行かなきゃいけません。（これを「読み込み」と呼びます）

この「倉庫まで取りに行く」という作業、実はめちゃくちゃ時間がかかるんです。人間でいえば、立ち上がって、階段を登って、重い本を探しに行くようなもの。これが頻繁に発生すると、システムは一気に重くなってしまいますよね。

『EXPLAIN BUFFERS』を実行すると、PostgreSQLはこんな感じの「作業報告書（レシート）」を返してくれます。

つまり、このコマンドを打つだけで、「あ、この処理は倉庫まで何回も往復しているから遅いんだな」ということが一発で分かるんです。

使い方はとっても簡単です。普段実行しているSQL文の先頭に、おまじないのように `EXPLAIN (ANALYZE, BUFFERS)` を付けるだけ。

EXPLAIN (ANALYZE, BUFFERS)
SELECT FROM users WHERE status = ‘active’;

これだけで、PostgreSQLが「このクエリを処理するのに、メモリをどれくらい使って、ディスクから何回データを引っ張ってきたか」を事細かに教えてくれます。

もし結果を見て、「Read（倉庫への往復）が多すぎる！」と分かったら、そこが改善のチャンスです。

原因が分かれば、対策は自然と見えてきます。「なんとなく重いなあ」と悩んでいた時間が、このコマンド一つで「あ、ここを直せばいいのか！」という確信に変わる瞬間、エンジニアとして最高に気持ちいい瞬間なんですよ。

—

データベースのパフォーマンスチューニングと聞くと、「なんだか難しそうだし、壊しちゃいそう…」と不安になるかもしれません。でも大丈夫。`EXPLAIN`は、あくまで「今の状態を教えてくれるだけ」の優しいツールです。データを書き換えたりすることはないので、安心して覗いてみてください。

「自分の書いたSQLが、データベースの中でどんな旅をしているのか」。それを覗き見するだけで、データベースと少し仲良くなれたような気分になれますよ。

皆さんのシステムが、今日もサクサク快適に動きますように！また次回のブログでお会いしましょう。