統計情報は「クエリプランナの目」である。その解像度をいかに最適化するか
PostgreSQLのクエリチューニングにおいて、最も軽視されがちでありながら、最も重大な影響を及ぼすのが「統計情報（Statistics）」です。
多くのエンジニアが「遅いクエリ」に直面したとき、真っ先に`EXPLAIN ANALYZE`を叩き、インデックスの追加やクエリの書き換えを検討します。しかし、ベテランならまず確認すべきは、プランナが使用している統計情報の「鮮度」と「精度」です。
プランナは、膨大な検索空間から実行計画を選ぶ際、統計情報を「地図」として参照します。地図が古ければ、当然、最適解に辿り着くことはできません。
統計情報の「心臓部」を理解する
PostgreSQLの統計情報は、主に`pg_statistic`システムカタログに格納されています。ここには、単なる行数（`reltuples`）だけでなく、各カラムのデータ分布、nullの割合、そして何より重要な「MCV（Most Common Values）」と「ヒストグラム」が含まれています。
プランナはこれらを使って、`WHERE`句の選択率（Selectivity）を算出します。もし、この統計情報が現実のデータ分布とかけ離れていれば、プランナは「数行しか返さないはずのクエリ」に対して「全件走査（Sequential Scan）」ではなく「インデックススキャン」を選択し、結果として悲惨なパフォーマンスを招くことになります。
なぜ「デフォルト」では足りないのか
PostgreSQLの自動統計収集（autovacuum）は非常に優秀です。しかし、特定のカラムで「データが極端に偏っている場合」や「値同士の相関がある場合」には、デフォルト設定では力不足です。
例えば、あるカラムで「特定のフラグが99%を占め、残りの1%を検索したい」といったケース。デフォルトのヒストグラムのバケット数（`default_statistics_target`）では、その微小な1%の分布を捉えきれず、プランナは「全件走査の方が速い」と誤判定しがちです。
ここで、現場のエンジニアが取るべき一手は「特定のカラムに対する統計精度の引き上げ」です。
ALTER TABLE orders ALTER COLUMN status SET STATISTICS 500;
ANALYZE orders;
このように、カラム単位で統計ターゲットを上げるだけで、プランナが保持するヒストグラムの解像度が跳ね上がります。これは「なんとなくインデックスを貼る」よりも、遥かに本質的な最適化です。
統計情報の「盲点」：相関をどう教えるか
PostgreSQLのプランナは、基本的には各カラムが独立していると仮定して計算します（※最近のバージョンでは多変量統計も進化していますが）。
例えば、「都市カラム」と「郵便番号カラム」は強く相関しています。しかし、プランナはこれらを別々に計算するため、選択率の積算がおかしくなり、見積もり行数が指数関数的にズレることがあります。
この問題に対しては、`CREATE STATISTICS`を用いた「多変量統計」の定義が特効薬です。
CREATE STATISTICS stx_city_zip (dependencies) ON city, zip_code FROM orders;
これを定義することで、プランナは「都市が決まれば郵便番号も自ずと決まる」という依存関係を理解し、劇的に見積もり精度が向上します。これは、大規模なデータセットを扱う際に「神の一手」となることが多いテクニックです。
パフォーマンストラブルシューティングの極意
もし、あなたが「なぜか実行計画が不安定だ」というトラブルに直面したなら、まずは以下をチェックしてください。
1. `pg_stats`を覗き込む: `null_frac`や`n_distinct`の値が、実際のデータの感覚と一致しているか確認します。
2. `autoanalyze`のトリガーを確認: 更新頻度が激しいテーブルで、`autovacuum_analyze_scale_factor`が適切か。頻繁に変動するテーブルなら、もっと低く設定すべきかもしれません。
3. `ANALYZE`のタイミング: 大量データ更新の直後に`ANALYZE`が走っているか。あるいは、意図的に特定のタイミングで`ANALYZE`を手動実行すべきワークロードではないか。
最後に：プランナと対話する
統計情報の最適化とは、単なる設定変更ではなく、「データベースにデータの性格を教え込む作業」です。
プランナは機械的にコストを計算しますが、そのコスト計算の背後にあるのは、我々人間が与えた「統計という名の地図」です。この地図を磨き上げることで、データベースは驚くほど賢く振る舞い、過酷な負荷にも耐えうる実行計画を自ら導き出すようになります。
パフォーマンスチューニングの泥沼に足を取られたとき、まずは「統計情報は正しいか？」と自問自答してみてください。その一歩が、最もシンプルで、かつ最強の解決策になるはずです。
コメント