SQL集計クエリで実務レビューされやすいGROUP BYとHAVINGの考え方

SQL 集計 設計は集計前と集計後の条件分けから考える

SQL 集計 設計でレビューされやすいのは、GROUP BYを書けているかではありません。むしろ、どの粒度で集計するか、WHEREとHAVINGの条件を分けているかが見られます。さらに、COUNTやSUMの結果が業務上の意味と合っているかも、実務では重要です。

結論から言うと、集計クエリは「集計前に対象行を絞る条件」と「集計後の結果に対する条件」を分けて設計します。さらに、NULL、重複、JOIN後の行増加、実行計画を確認します。

GROUP BYは集計の粒度を決める設計

GROUP BYは、単に同じ値をまとめる構文ではありません。例えば、売上を店舗別に見るのか、店舗と月別に見るのか、担当者別に見るのかを決める設計です。なお、PostgreSQLのSELECT公式ドキュメントでも、GROUP BYは行をグループ化して集計する句として扱われます。

SELECT store_id, DATE_TRUNC('month', ordered_at) AS order_month,
       COUNT(*) AS order_count,
       SUM(amount) AS total_amount
FROM orders
WHERE ordered_at >= DATE '2026-01-01'
  AND status = 'PAID'
GROUP BY store_id, DATE_TRUNC('month', ordered_at);

この例では、集計粒度は「店舗 x 月」です。そのため、レビューでは、SELECTに出している列とGROUP BYの粒度が一致しているかを確認します。粒度が曖昧だと、数字は出ても業務判断に使えません。

HAVINGは集計後の条件にだけ使う

HAVINGは、集計した結果に対する条件です。例えば「月間注文数が10件以上の店舗」を探す場合は、COUNTの結果を使います。そのため、この条件はHAVINGに置きます。

SELECT store_id, COUNT(*) AS order_count
FROM orders
WHERE status = 'PAID'
GROUP BY store_id
HAVING COUNT(*) >= 10;

一方で、支払い済みだけを対象にする条件はWHEREです。WHEREで先に絞れる条件をHAVINGへ置くと、不要な行まで集計対象になります。その結果、性能面でも読みやすさの面でも、レビューで指摘されやすい書き方になります。

WHEREとHAVINGの判断表

条件の種類	置く場所	例	レビュー観点
集計前の行条件	WHERE	status = ‘PAID’	先に絞れているか
期間条件	WHERE	ordered_at >= ‘2026-01-01’	インデックスを使えるか
件数の条件	HAVING	COUNT(*) >= 10	集計結果への条件か
合計金額の条件	HAVING	SUM(amount) > 100000	NULLや重複を考慮したか

SQL集計クエリで失敗しやすいCOUNTとSUM

集計関数は、使い分けを間違えると数字が静かにズレます。そこで、PostgreSQLのAggregate FunctionsやMySQLのGROUP BY Handlingも確認しながら、DBごとの差分を意識する必要があります。

• COUNT(*) は行数を数える
• COUNT(column) はNULLでない値だけを数える
• SUM(amount) はJOINで行が増えると二重計上しやすい
• COUNT(DISTINCT user_id) は意図を明確にするが、性能確認が必要

特に、明細テーブルをJOINした後に注文金額をSUMするケースは注意が必要です。注文1件に明細が3件あれば、注文金額も3回足される可能性があります。そのため、先に注文単位へ集約してからJOINするか、集計対象のテーブルを見直します。

レビュー前に確認したいSQL 集計 設計チェックリスト

• 集計粒度を一文で説明できるか
• WHEREとHAVINGの条件が分かれているか
• COUNT(*)とCOUNT(column)の差を考慮したか
• JOINで行数が増えていないか
• 期間条件やステータス条件に必要なインデックスがあるか
• 実行計画で想定外の全表走査や大きなソートが出ていないか

まとめ

SQL集計クエリは、構文よりも設計意図が重要です。まずGROUP BYで粒度を決め、WHEREで集計前に絞り、HAVINGで集計後の結果を判定します。さらに、COUNT、SUM、JOIN、NULL、実行計画まで見ると、レビューで説明しやすいクエリになります。

また、Java/Spring BootやSQLを使う案件では、集計クエリの設計力が業務理解やレビュー品質に直結します。今の経験をどう活かせる案件があるか整理したい場合は、カジュアル面談で現在の担当範囲から一緒に確認できます。