NULL値がAVG関数の結果を歪めるメカニズム
DBAとして現場でログ解析やデータ集計を支援していると、AVG関数に関する「直感との乖離」に頭を抱える開発者の方によく出会います。最も注意すべき点は、AVG関数はNULL値を計算対象から除外するという仕様です。
例えば、売上データで「0円」の注文と「NULL（未入金やデータ欠損）」を混同すると危険です。10件のデータのうち、5件が100円、5件がNULLだった場合、AVGの結果は50円ではなく100円になります。これは「NULLは0として扱われる」と誤解していると、経営判断を誤らせる大きなリスクとなります。
実務における「0補完」のベストプラクティス
上記の問題を防ぐため、実務ではCOALESCE関数を併用することが定石です。
SELECT AVG(COALESCE(price, 0)) FROM sales;
このように記述することで、NULLを明示的に0へ変換し、全件を母数とした真の平均値を算出できます。「データが存在しないこと」と「値が0であること」を業務的にどう定義するか、クエリを書く前に改めて要件を確認してください。
大量データにおけるパフォーマンスの落とし穴
もう一つ、大規模テーブルでAVG関数を使う際の注意点があります。それは、集計対象カラムにインデックスが効きにくいケースがあるということです。
特にWHERE句で絞り込んだ結果に対してAVGを計算する場合、インデックスがフルスキャンを回避できているか実行計画を確認してください。もし、頻繁に特定期間の平均値を算出するダッシュボード用途であれば、AVGを直接計算し続けるのではなく、日次や月次の「集計済みテーブル」を別途作成しておくべきです。
まとめ：数値の「意味」を設計に落とし込む
AVG関数はシンプルですが、扱うデータの「NULLの意味」と「計算のコスト」を意識するだけで、生成されるレポートの信頼性は劇的に向上します。クエリを叩く前に、「このNULLは計算から省くべきなのか、それとも0としてカウントすべきなのか」を一度立ち止まって考えてみてください。それが、データ品質を守るプロのDBAの流儀です。
コメント