「検索が遅い!」を解決する名探偵への道。PostgreSQLの『EXPLAIN ANALYZE』を読み解こう
データベースを触っていると、「あれ、なんか最近レスポンスが遅いな?」なんて感じること、ありますよね。そんな時、あなたは闇雲にインデックスを貼ったりしていませんか?
実はそれ、例えるなら「家のどこに鍵を置いたか忘れたのに、家中をひっくり返して掃除している」ようなものかもしれません。
PostgreSQLには、そんな迷子を救い出してくれる最高のツールがあります。それが`EXPLAIN ANALYZE`です。今日は、この魔法の呪文を使って、データベースの「裏側の動き」を覗き見する方法を、一緒に紐解いていきましょう!
—
「EXPLAIN ANALYZE」って何者?
簡単に言えば、「データベースがクエリを実行するまでの『行動予定表』と『実際の成績表』」です。
SQLの頭にこの魔法の言葉をつけるだけで、データベースは「私はこれからこうやって探して、実際にはこれくらいの時間がかかりました!」と詳細なレポートを提出してくれます。
使い方は簡単。いつも実行しているSQLの前に付けるだけです。
EXPLAIN ANALYZE SELECT FROM users WHERE email = ‘test@example.com’;
これだけで、画面にズラズラと英語が出てきます。初めて見た時は「なんだこれ!」と閉じたくなりますよね。でも大丈夫。まずは3つのポイントだけ押さえればOKです。
—
ボトルネックを見つける「3つのチェックポイント」
レポートの中から、まずは以下の3点に注目してみましょう。
1. 「コスト(cost)」:予測されるエネルギー消費量
これは「この検索をするのにどれくらい疲れそうか」という目安です。
- ポイント: `cost=0.00..12.50` のように表示されます。この数字が大きいほど、「大変な作業」だとデータベースが判断しています。もし特定のクエリでこの数字が異常に高いなら、そこが改善の余地あり!というサインです。
2. 「行数(rows)」:届いた荷物の量
「実際に何件のデータに触ったか」を表します。
- ポイント: 100件しか必要ないのに、100万件のテーブルを全部スキャンして(Seq Scan)、その結果100件だけ抽出している……なんて状態になっていませんか?これは、わざわざ倉庫の端から端まで歩いて探し物をしているようなもの。インデックスの出番です!
3. 「ループ回数(loops)」と「時間(time)」:かかった手間暇
ここが一番の核心です。特に「ループ回数」に注目してください。
- ポイント: もしループ回数が多いなら、何度も何度も同じ場所を往復している証拠。また、`Shared Hit`(メモリから見つかった)と `Shared Read`(ディスクまで探しに行った)の数字を見てください。`Read`が多いということは、メモリに乗っていないデータをわざわざ遠い倉庫まで取りに行っているということ。これが「遅い」の正体です。
—
効率的な検索のための「引き出し」を作ろう
もし、レポートを見て「ああ、全件スキャン(Seq Scan)しちゃってるな」と気づいたら、それはインデックスという「引き出し」が足りない合図です。
例えるなら、図書館で本を探すとき、検索機を使わずに全ての棚を端からチェックしているような状態です。インデックスを貼ることは、図書館に「あいうえお順の索引」を作るようなもの。これだけで、劇的に速くなることがよくあります。
—
最後に:怖がらずに、実験してみよう
`EXPLAIN ANALYZE`は、決して難しい専門家のための道具ではありません。
「これを実行したら、データベースはどう動くんだろう?」と好奇心を持って眺めるだけで、あなたのエンジニアとしての直感はどんどん磨かれていきます。
最初から完璧に読めなくても大丈夫。まずは「どこで時間がかかっているのかな?」と眺めることから始めてみてください。少しずつ、データベースの「心の声」が聞こえてくるようになりますよ。
さあ、あなたのデータベースの裏側、今日はどんな物語を語ってくれるでしょうか?ぜひ試してみてくださいね!
コメント