統計情報とオプティマイザ

インデックスを使うかどうかは統計情報が決める

DBの中では「クエリオプティマイザ」がSQLを見て、複数の実行計画候補の中からコスト最小のものを選びます。 このコスト見積りは統計情報（各カラムの値の分布、行数、NULL率など）に基づきます。

インデックスを使わない判断もある

テーブルの多くの行が該当するクエリでは、インデックス経由でランダムアクセスを繰り返すよりもフルスキャンの方が速い。 オプティマイザはこれを見積りコストで判断します。「インデックスを貼ったのに使われない」の原因のほとんどは、この見積りで「使わない方が速い」と判断されているか、統計情報が古くて誤った判断が下されているかのどちらかです。

統計情報が古いとどうなるか

• 大量INSERT直後: 実際にはインデックスが効かない量なのにインデックスを選んでしまう
• 大量DELETE直後: インデックスが有効なのに、統計上「多くの行が該当する」と誤認して使わない
• データ分布の変化: 元は偏っていたstatusが均等になったのに古い分布で判断してしまう

こうした場合は、統計情報を更新するコマンドを実行して最新の分布に合わせます（コマンド名はRDBMSごとに異なる）。

MySQL の統計情報

MySQL の InnoDB は、統計情報を mysql.innodb_table_stats とmysql.innodb_index_stats の 2 テーブルに永続化する。行数見積り、 インデックスごとのカーディナリティ、リーフページ数などが並ぶ。

更新のトリガーは 2 つ。

• 自動: innodb_stats_auto_recalc が ON (デフォルト) の場合、 テーブルの行数が約 10% 変化したタイミングでバックグラウンドスレッドが再計算する。
• 手動: ANALYZE TABLE table_name; を実行すると即時に統計を採り直す。 バルクロード直後・大量削除直後・想定と実行計画がズレたときはこれを打つ。

サンプリング精度は innodb_stats_persistent_sample_pages (デフォルト 20 ページ) で調整可能。 巨大テーブルで見積り誤差が大きいときは増やす。 なお MySQL 8.0 からは ヒストグラム ( ANALYZE TABLE ... UPDATE HISTOGRAM ON col;) が使えるようになり、値の偏ったカラム (例: status に 90% が同じ値) の見積り精度が上がる。

PostgreSQL の統計情報

PostgreSQL の統計情報はシステムカタログ pg_statistic に格納される。 直接読むのは面倒なので、通常は pg_stats ビュー越しに参照する (行数・NULL 率・最頻値 most_common_vals・ヒストグラム境界 histogram_boundsなどが人間可読な形で並ぶ)。

更新のトリガーは 2 つ。

• 自動: autovacuum ワーカーが VACUUM とセットで ANALYZE も回す。autovacuum_analyze_scale_factor (デフォルト 0.1) とautovacuum_analyze_threshold (デフォルト 50) で発火条件が決まる。
• 手動: ANALYZE table_name; または VACUUM ANALYZE table_name;。 後者は VACUUM も同時に実行する。バルクロード後は必ず手で打つのが安全。

サンプリング粒度は default_statistics_target (デフォルト 100) で決まり、 列単位に ALTER TABLE ... ALTER COLUMN col SET STATISTICS 1000; で上書きできる。 偏りが大きいカラムはターゲット値を上げると most_common_vals の候補数と ヒストグラム境界数が増え、見積り精度が改善する。

EXPLAIN ANALYZE で「見積り行数」と「実際の行数」が大きくズレていたら、 まず ANALYZE を疑うのが定石。