One of my first questions would be how was it determined that a SELECT statement was using 100% CPU? The duration of the 100% CPU usage, if in fact it existed, is also important. Does the server only have a single CPU core, or is the query implementing parallel query? What more important task is interrupted when the query uses a lot of CPU time?

It might be worthwhile to look at a couple of execution plans that were previously provided by a reader (see: http://hoopercharles.wordpress.com/2011/01/03/no_query_transformation-hint-is-ignored-well-almost-ignored/#comment-2597 )

SQL_ID  3u689tu6mfkdw, child number 0
-------------------------------------
select count(*) from kso.little_skew a left outer join kso.little_skew
b on a.pk_col = b.pk_col
 
Plan hash value: 1386718486
 
---------------------------------------------------------------------------------------------------
| Id  | Operation                   | Name        | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |             |       |       |       |  4984 (100)|          |
|   1 |  SORT AGGREGATE             |             |     1 |    12 |       |            |          |
|*  2 |   HASH JOIN OUTER           |             |  1210K|    13M|    18M|  4984   (1)| 00:01:00 |
|   3 |    TABLE ACCESS STORAGE FULL| LITTLE_SKEW |  1100K|  6445K|       |  1546   (1)| 00:00:19 |
|   4 |    TABLE ACCESS STORAGE FULL| LITTLE_SKEW |  1100K|  6445K|       |  1546   (1)| 00:00:19 |
---------------------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - access("A"."PK_COL"="B"."PK_COL")

SQL_ID  6x3g2dtmwgvyu, child number 0
-------------------------------------
select /*+ NO_QUERY_TRANSFORMATION */ count(*) from kso.little_skew a
left outer join kso.little_skew b on a.pk_col = b.pk_col
 
Plan hash value: 2156590542
 
---------------------------------------------------------------------------------------------
| Id  | Operation                     | Name        | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT              |             |       |       |  1703M(100)|          |
|   1 |  SORT AGGREGATE               |             |     1 |       |            |          |
|   2 |   VIEW                        |             |    12G|       |  1703M  (1)|999:59:59 |
|   3 |    NESTED LOOPS OUTER         |             |    12G|    67G|  1703M  (1)|999:59:59 |
|   4 |     TABLE ACCESS STORAGE FULL | LITTLE_SKEW |  1100K|  6445K|  1546   (1)| 00:00:19 |
|   5 |     VIEW                      |             | 11001 |       |  1548   (1)| 00:00:19 |
|*  6 |      TABLE ACCESS STORAGE FULL| LITTLE_SKEW | 11001 | 66006 |  1548   (1)| 00:00:19 |
---------------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
   6 - filter("A"."PK_COL"="B"."PK_COL")

Is it the 100 in the Cost (%CPU) column that is of concern? Both of the above execution plans show the same (100) value on the first line of the execution plans.

(Edit Feb 15, 2013 – I just noticed that Tanel Poder posted a related blog article yesterday that describes an approach to troubleshooting excessive CPU utilization for a SQL statement: http://blog.tanelpoder.com/2013/02/14/troubleshooting-high-cpu-usage-with-poor-mans-stack-profiler-in-a-one-liner/ )

The blog article intentionally suggests in a subtle (but possibly humorous) way that maybe a distinction is necessary. Is the SQL statement performing necessary work, and if so, what does it indicate when that SQL statement uses 100% CPU? In such a case, is it necessarily bad that the SQL statement uses 100% of the CPU, or is that level of CPU consumption possibly ideal. What is the alternative to using CPU… would it be better or worse if the session were instead in a wait event rather than consuming CPU time?

That resolves to billions of rows. When any and all tables in the query have only hundreds or thousands or rows.

I’ve come up with 5 ways to get cartesian product in a SQL query. See my research and presentation here:
http://rodgersnotes.wordpress.com/2010/09/15/stamping-out-cartesian-products/