HAVING filters groups. It goes after GROUP BY and keeps only the groups that meet a condition on an aggregate function: customers with more than one order, products that add up to more than $1,000, and so on.

Syntax
SELECT columns, aggregateFunction(column)
FROM table
WHERE conditionOnRows
GROUP BY columns
HAVING conditionOnGroups;

HAVING vs WHERE

Both filter, but at different moments of the query:

Clause What it filters When it runs Allows aggregate functions?
WHERE Rows Before grouping No
HAVING Groups After grouping Yes

That is why this query fails: when WHERE is evaluated the groups don’t exist yet, so COUNT(*) means nothing.

PostgreSQL in your browser · Ctrl+Enter to run · changes are rolled back afterwards
Aggregate functions are not allowed in the WHERE clause. SQL Server reports it with a message like: An aggregate may not appear in the WHERE clause unless it is in a subquery contained in a HAVING clause or a select list.

Basic example

The right way to get the customers with more than one order is to move the condition to HAVING:

PostgreSQL in your browser · Ctrl+Enter to run · changes are rolled back afterwards
customerId orders
2 2
4 2

Only Mavin (customerId = 2) and Helen (customerId = 4) have placed more than one order.

HAVING with SUM

Any aggregate function works. Here, the customers whose total spending is over $3,000, joined to Customers to show their names:

PostgreSQL in your browser · Ctrl+Enter to run · changes are rolled back afterwards
name lastName totalSpent
Helen Ward 4999.00
Peter Davis 4304.25
Mavin Pettitt 3199.78

WHERE and HAVING in the same query

They are usually combined: WHERE drops rows before grouping and HAVING drops groups afterwards. This query counts, per product description, how many orders were placed from July 2022 onwards, and keeps only the descriptions with at least two:

PostgreSQL in your browser · Ctrl+Enter to run · changes are rolled back afterwards
productDescription orders units
Alexa Speaker 2 100

The order in which the engine processes a query makes this easier to follow:

  1. FROM and JOIN: which tables are involved.
  2. WHERE: which rows stay.
  3. GROUP BY: how they are grouped.
  4. HAVING: which groups stay.
  5. SELECT: which columns are returned.
  6. ORDER BY: in what order.
If a condition doesn’t use aggregate functions, put it in WHERE even if it would also work in HAVING: the engine discards the rows before grouping and does less work.

Common mistakes

  • Using a SELECT alias in HAVING. HAVING orders > 1 works in some engines, such as MySQL, but not in SQL Server, because HAVING is evaluated before SELECT. Repeat the expression: HAVING COUNT(*) > 1.
  • Forgetting GROUP BY. Without it the whole table is a single group, and HAVING returns one row or none.
  • Filtering on a column that isn’t grouped. Only GROUP BY columns or aggregate functions can appear in HAVING.

Practice

Change the examples above to answer these questions:

  1. Which customers have bought more than 50 units in total? (Hint: SUM(productQuantity).)
  2. Which product descriptions have an average price above $400?
  3. What happens if you change >= 2 to >= 1 in the last example?