「あれ、この検索なんでこんなに遅いの？」を解決する！PostgreSQLのちょっと賢い統計係数のお話
みなさん、こんにちは！データベースを触っていると、「さっきまでサクサク動いていたクエリが、急に重くなった……」なんて経験、一度はありますよね。
特に、`GROUP BY` を使ってデータを集計するとき、「なんでデータベースくんは、こんなに遠回りなやり方を選んじゃうの？」と頭を抱えたくなること、ありませんか？
実は、PostgreSQLには「データの実態を正しく教えてあげる」ための、ちょっとした秘密兵器があるんです。今日は、専門用語を極力使わずに、「n-distinct係数」という魔法の杖についてお話ししますね。
—
なぜデータベースは「思い込み」をしてしまうのか？
まず、身近な例で考えてみましょう。
あなたは大きな図書館の司書さんだと想像してください。本棚には数万冊の本があります。「『料理』というジャンルで、かつ『イタリアン』の本は何冊ある？」と聞かれたら、あなたはこれまでの経験から「だいたいこれくらいかな」と目星をつけて探しに行きますよね。
PostgreSQLも同じです。クエリを実行する前に、「この条件なら、結果はこれくらい返ってくるはずだから、この方法で探そう！」と見積もり（プラン）を立てます。
でも、もしデータベースが「料理」と「イタリアン」の組み合わせのユニークさ（n-distinct）を全く知らなかったらどうなるでしょう？
「うーん、料理の本とイタリアンの本は別々に数えたことはあるけど、組み合わさったときにどれくらい種類があるかは知らないや。……とりあえず、全部の本を一度机に並べてから数えよう！」
……はい、これが「クエリが遅くなる原因」の正体です。「全部並べる」という非効率な方法を選んでしまっているんですね。
—
「n-distinct係数」は、いわば「情報の解像度を上げるメガネ」
ここで登場するのが、今回のテーマである「n-distinct係数（拡張統計）」です。
これは簡単に言うと、データベースに対して「『料理』かつ『イタリアン』の組み合わせって、実はこれくらいの種類があるんだよ」という具体的なメモを渡してあげることなんです。
- なし（デフォルト）: 「料理」と「イタリアン」を別々に評価。「たぶん、組み合わせてもたくさん種類があるはずだ（適当）」
- あり（拡張統計）: 「『料理×イタリアン』の組み合わせは、実はこれくらいユニークな値があるんだよ」という統計を記録。
これを知っているだけで、データベースは「あ、わざわざ全部並べなくても、この棚だけ見れば答えが出るじゃん！」と、最短ルートに気づいてくれるようになります。
—
どんな時に使えばいいの？
すべてのテーブルに設定する必要はありません。むしろ、何でもかんでも設定すると管理が大変になってしまいます。
例えば、こんな場面で困っていたら思い出してみてください。
- 「2つの列（例：都道府県と市区町村）でグループ化しているクエリが、やたらと遅い」
- 「データ量はそこまで多くないのに、データベースが変な計算手順を選んでいる気がする」
もし心当たりがあれば、`CREATE STATISTICS` というコマンドで、「この列とこの列の組み合わせはよく一緒に検索するから、統計を取っておいてね」と指示を出してみてください。これだけで、劇的にレスポンスが改善することがあります。
—
まとめ：データベースとの対話を深めよう
データベースというのは、ある意味で「とても優秀だけど、想像力が少し足りない相棒」のようなものです。
私たちが「このデータとこのデータの組み合わせは、こういう特徴があるよ」と少し教えてあげるだけで、あの子は驚くほど賢く立ち回ってくれるようになります。
「n-distinct係数」なんて難しい名前がついていますが、要は「データベースに現実世界の情報の偏りを教えてあげること」。これさえ覚えておけば、チューニングの幅がグッと広がりますよ！
ぜひ、みなさんの環境でも「最近遅いな」と感じるクエリがあれば、統計情報を一度見直してみてくださいね。それでは、また次回の記事でお会いしましょう！
コメント