SQL Tip of the Day: Be Wary of SELECT COUNT(*)
Recently, I’ve encountered this sort of query all over the place at a customer site:
DECLARE v_var NUMBER(10); BEGIN SELECT COUNT(*) INTO v_var FROM table1 JOIN table2 ON table1.t1_id = table2.t1_id JOIN table3 ON table2.t2_id = table3.t2_id ... WHERE some_predicate; IF (v_var = 1) THEN do_something ELSE do_something_else END IF; END;
Unfortunately, COUNT(*)
is often the first solution that comes to mind when we want to check our relations for some predicate. But COUNT()
is expensive, especially if all we’re doing is checking our relations for existence. Does the word ring a bell? Yes, we should use the EXISTS
predicate, because if we don’t care about the exact number of records that return true for a given predicate, we shouldn’t go through the complete data set to actually count the exact number. The above PL/SQL block can be rewritten trivially to this one:
DECLARE v_var NUMBER(10); BEGIN SELECT CASE WHEN EXISTS ( SELECT 1 FROM table1 JOIN table2 ON table1.t1_id = table2.t1_id JOIN table3 ON table2.t2_id = table3.t2_id ... WHERE some_predicate ) THEN 1 ELSE 0 END INTO v_var FROM dual; IF (v_var = 1) THEN do_something ELSE do_something_else END IF; END;
Let’s measure!
Query 1 yields this execution plan:
----------------------------------------------- | Id | Operation | E-Rows | A-Rows | ----------------------------------------------- | 0 | SELECT STATEMENT | | 1 | | 1 | SORT AGGREGATE | 1 | 1 | |* 2 | HASH JOIN | 4 | 4 | |* 3 | TABLE ACCESS FULL| 2 | 2 | |* 4 | TABLE ACCESS FULL| 6 | 6 | -----------------------------------------------
Query 2 yields this execution plan:
---------------------------------------------- | Id | Operation | E-Rows | A-Rows | ---------------------------------------------- | 0 | SELECT STATEMENT | | 1 | | 1 | NESTED LOOPS | 4 | 1 | |* 2 | TABLE ACCESS FULL| 2 | 1 | |* 3 | TABLE ACCESS FULL| 2 | 1 | | 4 | FAST DUAL | 1 | 1 | ----------------------------------------------
You can ignore the TABLE ACCESS FULL
operations, the actual query was executed on a trivial database with no indexes.
What’s essential, however, are the much improved E-Rows
values (E = Estimated) and even more importantly the optimal A-Rows
values (A = Actual). As you can see, the EXISTS
predicate could be aborted early, as soon as the first record that matches the predicate is encountered – in this case immediately.
See this post about more details of how to collect Oracle Execution plans
Conclusion
Whenever you encounter a COUNT(*)
operation, you should ask yourself if it is really needed. Do you really need to know the exact number of records that match a predicate? Or are you already happy knowing that any record matches the predicate?
Answer: It’s probably the latter.
Reference: | SQL Tip of the Day: Be Wary of SELECT COUNT(*) from our JCG partner Lukas Eder at the JAVA, SQL, AND JOOQ blog. |
The first pl/sql can be simply changed by restricting the number of rows to 1 using rownum or limit clauses as shown below.
SELECT 1
INTO v_var
FROM table1
JOIN table2 ON table1.t1_id = table2.t1_id
JOIN table3 ON table2.t2_id = table3.t2_id
….
WHERE some_predicate LIMIT 1;
The reason why COUNT(*) was chosen in the first place was to avoid catching NO_DATA_FOUND exceptions – which was perceived to be verbose. Otherwise, you’re right, of course.
I would still prefer the EXISTS solution. It is more explicit in the first place and thereby communicates the intention of the query better. Furthermore LIMIT is not supported by various DBMS.
Limit (or an equivalent thereof) is supported by pretty much every database. For details see this link here:
http://www.jooq.org/doc/latest/manual/sql-building/sql-statements/select-statement/limit-clause
But of course, EXISTS better communicates the intent of this particular use-case than both COUNT(*) and LIMIT