Which SQL statement is faster? (HAVING vs. WHERE...)

SqlPerformanceGroupingIf Statement

Sql Problem Overview


SELECT NR_DZIALU, COUNT (NR_DZIALU) AS LICZ_PRAC_DZIALU
    FROM  PRACOWNICY
    GROUP BY NR_DZIALU
    HAVING NR_DZIALU = 30

or

SELECT NR_DZIALU, COUNT (NR_DZIALU) AS LICZ_PRAC_DZIALU
    FROM PRACOWNICY
    WHERE NR_DZIALU = 30
    GROUP BY NR_DZIALU

Sql Solutions


Solution 1 - Sql

The theory (by theory I mean SQL Standard) says that WHERE restricts the result set before returning rows and HAVING restricts the result set after bringing all the rows. So WHERE is faster. On SQL Standard compliant DBMSs in this regard, only use HAVING where you cannot put the condition on a WHERE (like computed columns in some RDBMSs.)

You can just see the execution plan for both and check for yourself, nothing will beat that (measurement for your specific query in your specific environment with your data.)

Solution 2 - Sql

It might depend on the engine. MySQL for example, applies HAVING almost last in the chain, meaning there is almost no room for optimization. From the manual:

> The HAVING clause is applied nearly last, just before items are sent to the client, with no optimization. (LIMIT is applied after HAVING.)

I believe this behavior is the same in most SQL database engines, but I can't guarantee it.

Solution 3 - Sql

The two queries are equivalent and your DBMS query optimizer should recognise this and produce the same query plan. It may not, but the situation is fairly simple to recognise, so I'd expect any modern system - even Sybase - to deal with it.

HAVING clauses should be used to apply conditions on group functions, otherwise they can be moved into the WHERE condition. For example. if you wanted to restrict your query to groups that have COUNT(DZIALU) > 10, say, you would need to put the condition into a HAVING because it acts on the groups, not the individual rows.

Solution 4 - Sql

I'd expect the WHERE clause would be faster, but it's possible they'd optimize to exactly the same.

Solution 5 - Sql

Saying they would optimize is not really taking control and telling the computer what to do. I would agree that the use of having is not an alternative to a where clause. Having has a special usage of being applied to a group by where something like a sum() was used and you want to limit the result set to show only groups having a sum() > than 100 per se. Having works on groups, Where works on rows. They are apples and oranges. So really, they should not be compared as they are two very different animals.

Solution 6 - Sql

"WHERE" is faster than "HAVING"!

The more complex grouping of the query is - the slower "HAVING" will perform to compare because: "HAVING" "filter" will deal with larger amount of results and its also being additional "filter" loop

"HAVING" will also use more memory (RAM)

Altho when working with small data - the difference is minor and can absolutely be ignored

Solution 7 - Sql

"Having" is slower if we compare with large amount of data because it works on group of records and "WHERE" works on number of rows..

"Where" restricts results before bringing all rows and 'Having" restricts results after bringing all the rows

Solution 8 - Sql

Both the statements will be having same performance as SQL Server is smart enough to parse both the same statements into a similar plan.

So, it does not matter if you use WHERE or HAVING in your query.

But, ideally you should use WHERE clause syntactically.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionM_1View Question on Stackoverflow
Solution 1 - SqlVinko VrsalovicView Answer on Stackoverflow
Solution 2 - SqlEran GalperinView Answer on Stackoverflow
Solution 3 - SqlMike WoodhouseView Answer on Stackoverflow
Solution 4 - SqlysthView Answer on Stackoverflow
Solution 5 - SqlprogrammerView Answer on Stackoverflow
Solution 6 - SqlMarius GriView Answer on Stackoverflow
Solution 7 - SqlNitish BhardwajView Answer on Stackoverflow
Solution 8 - SqlManoj PandeyView Answer on Stackoverflow