こんにちは！データベースの世界にどっぷり浸かっているエンジニアです。
今日は、PostgreSQLのちょっと「通」な機能、「拡張統計情報（CREATE STATISTICS）」についてお話しします。
名前だけ聞くと「うわ、難しそう…」って思いますよね。でも大丈夫。これ、実は私たちの日常の「あるある」と全く同じ仕組みなんです。まずは、データベースがどうやって私たちのクエリを読み解いているのか、ちょっと想像してみてください。
—
データベースは「優秀だけど、ちょっと天然」？
PostgreSQLには「プランナ」という、司令塔のような存在がいます。「どうやってデータを取ってくるのが一番速いかな？」と、クエリごとに最適なルートを計算してくれる頼もしい奴です。
でも、このプランナ、「基本的には楽観的で、かつ個別の事情に疎い」という性格があるんです。
例えば、ある会員制サイトのデータベースを想像してください。
そこには「都道府県」と「郵便番号」という2つの列があるとします。
- 「東京都」のデータは全体の約10%
- 「100-0001」という郵便番号も、全体の約0.01%
これだけ分かっている状態で、「東京都」かつ「100-0001」の会員を探す命令を出したとき、プランナはどう考えるでしょうか？
何も教えなければ、プランナはこう計算します。
「東京都（10%）かつ、郵便番号（0.01%）だから…掛け算して、該当するのは全体の0.001%くらいだな！」
……お気づきですか？
「東京都の郵便番号なんだから、100%東京都の中にあるに決まってるだろ！」っていう、人間なら誰でも分かる「相関関係」を、プランナは知らないんです。
そこで登場！「拡張統計情報」
プランナは、別々の列の情報を組み合わせたときの「密接な関係」を推測するのが苦手です。その結果、見積もりが大きく外れて、本来なら爆速で終わるはずの処理が、とんでもない遠回り（非効率な検索）をしてしまうことがあります。
そんなとき、「おいおい、この2つの列はセットで考えるべきだぞ！」と教えてあげるのが『CREATE STATISTICS』なんです。
例えるなら、「この2つの列は仲良しグループだから、別々に計算しちゃダメだよ！」というカンニングペーパーをプランナに渡すようなものですね。
—
どうやって使うの？
使い方は驚くほどシンプルです。例えば、こんな感じでSQLを投げるだけ。
CREATE STATISTICS stats_city_zip
ON city, zip_code FROM users;
これだけで、PostgreSQLは「あ、この2つの列はセットで見ないとダメなんだね。よし、次はもっと正確に見積もるよ！」と賢くなってくれます。
どんなときに使うべき？
すべてのテーブルに設定する必要はありません。むしろ、やりすぎるとデータベースが統計を計算するのに忙しくなってしまいます。こんな場面で使ってみてください。
- 「絞り込み条件」を複数組み合わせているのに、なぜか処理が遅いとき。
- 「WHERE句で2つの列をセットで指定することが多い」とき。
- EXPLAIN ANALYZEを実行して、「見積もり行数」と「実際の行数」に天と地ほどの差があるとき。
—
最後に：完璧を目指さなくていい
データベースのチューニングって、パズルのようで楽しいですよね。でも、最初から完璧な設計なんて誰もできません。
「なんだかこのクエリ、遅い気がするな？」と感じたら、まずは今回紹介した拡張統計情報を思い出してみてください。「もしかして、列同士の仲良し関係がプランナに伝わってないのかも？」と疑ってみる。その視点を持つだけで、あなたはもう立派なDBエンジニアの仲間入りです。
また分からないことがあれば、いつでも聞きに来てくださいね。一緒にデータベースの深淵を覗いていきましょう！
コメント