Brightlane's operations team is investigating order-status distribution anomalies and needs to flag statuses that have exactly 11 orders on record.
Write a query to return each such status and its order count.
Assumptions:
- The
orderstable contains every order Brightlane has processed. - The match is on equality with 11, not a range — a status with 10 or 12 orders does not qualify.
Output:
- One row per status whose count is exactly 11, with columns
statusandorder_count.
Schema · ecommerce 5 tables
Run previews · Check grades
Write a query, then run it to see results here.
Worked solution Try it yourself first
SELECT
status,
COUNT(*) AS order_count
FROM
orders
GROUP BY
status
HAVING
COUNT(*) = 11The shape
HAVING COUNT(*) = 11 is an equality filter on the group's row count. GROUP BY status builds one row per distinct status with that status's count alongside; HAVING keeps only the rows whose count equals exactly 11. cancelled and pending both land at 11 and survive. delivered, with its much larger count, fails the equality and drops out: the comparison is =, not >=.
Clause by clause
SELECT status, COUNT(*) AS order_countreturns each surviving status with its order count.COUNT(*)reads every row in the group and returns the size.FROM ordersis the source set.GROUP BY statuspartitions the orders into one group per status value. After this clause, each row in the working set represents one status with its order count aggregated behind it.HAVING COUNT(*) = 11filters those status rows by exact-count equality. Statuses whose count is anything other than11(10, 12, 200) all drop out together. The operator matters more than the literal:>would have produced a different result set, and so would>=.
Why this and not > 10
A natural temptation is to read "exactly 11" as "at least 11" and reach for > 10 or >= 11. Those produce a wider result set. Any status with 11 or more orders would qualify, including delivered at whatever its true count is. The anomaly-investigation framing is the tell: operations isn't asking for thresholds, they're asking for a specific count value. Statuses above or below 11 are not interesting.
Every comparison operator that works in WHERE works the same way in HAVING. =, <>, <, >, <=, >=. The only difference is what sits on the left side: in WHERE a raw row value, in HAVING an aggregate. The operator semantics are identical.
The trap
The trap is reflexive. HAVING lessons usually frame thresholds as "more than N" or "at least N," so equality on a count feels unusual and learners drift toward a >-style filter. The prompt's word "exactly" is doing real work: a status with 12 orders is not the same anomaly as one with 11. = is the right operator.
The rule: HAVING is not specifically a "greater than" filter. It's a filter on aggregate values, and any comparison operator can sit in it. Match the operator to the question.
You practiced an equality-based HAVING filter. Equality (=), inequality (<>), and ranges all work in HAVING exactly as they do in WHERE — the only difference is what's on the left side: aggregate values rather than raw column values.
