【入門編】統計情報の陳腐化検知 – PostgreSQL

こんにちは！データベースの世界へようこそ。

普段、PostgreSQLを触っていると、「あれ、昨日までサクサク動いていたはずのクエリが、なんだか最近遅い気がする…」なんてこと、ありませんか？

実はそれ、データベースが「迷子」になっているサインかもしれません。今日は、そんなPostgreSQLの迷子を防ぐための「統計情報」という大切な仕組みについて、ちょっとした日常の例え話を交えながらお話ししますね。

—

まず、データベースがどうやってクエリ（命令）を処理しているか、想像してみてください。

例えば、あなたが知らない街に観光に行ったとします。「あの店に行きたい！」と思ったとき、あなたはスマホの地図アプリを見ますよね。でも、もしその地図が「3年前の古いもの」だったらどうでしょう？

これでは目的地になかなかたどり着けませんよね。データベースの世界でも同じことが起きています。

PostgreSQLは、クエリを実行するたびに「どの順番でデータを探せば一番早いか」を計算する「プランナー」という頭脳を持っています。その頭脳が参考にしているのが「統計情報」という名の地図なんです。

PostgreSQLは、テーブルの中身がどれくらい変わったかを定期的に見ています。「あ、またデータが増えたな」「結構書き換わったな」とチェックしているんです。

でも、あまりにも頻繁にデータの出し入れがあると、PostgreSQLは「ちょっと待って、今の状況を整理する時間が足りないよ！」となってしまいます。結果として、「今のデータ状況」と「持っている地図」にズレが生じてしまうわけです。

これが「統計情報の陳腐化（ちんぷか）」です。難しそうな言葉ですが、要は「古い地図のまま走り続けている状態」のことですね。

この「ズレ」を直す魔法の言葉が `ANALYZE` です。

`ANALYZE` を実行すると、PostgreSQLは一度立ち止まって、現在のテーブルの状態をしっかり確認し、「今の最新状況はこうだよ！」と地図を書き換えてくれます。

では、どうやって「今、地図を更新すべきタイミングかな？」と判断すればいいのでしょうか。

実は、PostgreSQLは自分自身で「どれくらいデータが変わったか」を記録しています。これを活用して、自分なりに「そろそろ更新したほうがいいかも」と判断できる仕組みを作ってみましょう。

以下のSQLを叩くと、テーブルごとに「どれくらいデータが入れ替わったか（死んだタプルといいます）」が見えてきます。

SELECT
relname AS テーブル名,
n_dead_tup AS 更新・削除された行数,
last_autovacuum AS 最後に自動更新された時間
FROM pg_stat_user_tables;

もし、`n_dead_tup`（更新や削除で不要になったデータ）の数値が異常に増えていたら、それは「地図がだいぶ古くなっていますよ！」という合図です。

—

「じゃあ、毎日手動で `ANALYZE` を打てばいいの？」と思うかもしれませんが、実はPostgreSQLには `autovacuum`（オートバキューム） という優秀な掃除係がいて、基本的には自動でやってくれています。

ただ、データの更新がものすごく激しいテーブルがある場合、この掃除係だけでは追いつかないことがあります。そんな時は、

1. まずは現状を確認する（さっきのSQLを使ってみてください！）
2. おかしいなと思ったら `ANALYZE テーブル名;` を手動で打ってみる

これだけで、クエリの速度が嘘みたいに改善することが本当によくあります。

データベースのチューニングと聞くと「なんだか難しそう」と身構えてしまうかもしれませんが、結局は「データベースが正しい地図を持っているかを確認してあげる」という、とてもシンプルな気遣いから始まります。

皆さんのデータベースも、たまには「最近どう？地図はちゃんと新しい？」と声をかけてあげてくださいね。きっと、今まで以上にキビキビと働いてくれるはずですよ！

それでは、また次回の記事でお会いしましょう！Happy Querying!