 |
|
SQL Server Tips by Burleson |
Nasty Join Operations
There are several join operations that should be avoided in a query.
Leading the pack is the Cartesian join. It normally appears only as
a coding mistake on the part of the user who issued the query. A
Cartesian join means there are two tables involved in a query that
have not been properly joined together through some relational
column pairing. For example:
select
patient_id
from
admission a,
patient b
where
patient_last_name like 'JUNG%'
The two tables in the above query have not been paired together
through a common relational column that is present in both tables;
therefore, SQL Server will have to utilize a Cartesian join. The
Cartesian join multiplies the number of rows in the first table by
the number of rows in the second table to arrive at the result set.
To guard against Cartesian joins, the standard rule of thumb is
there must be (N – 1) number of join predicates, where N represents
the number of tables in the FROM clause. A Cartesian product can be
spotted easily in the EXPLAIN as there will be a larger signaled
result set than expected.
Besides Cartesian joins, be on the lookout for other join operations
that can contribute to excessive run times. The most common
heavy-duty joins are hash and merge joins. These joins perform more
in-memory processing than nested loop joins, and therefore, the DBA
will see higher CPU and memory usage from these operations.
Often, indexing changes can transform the hash join into a nested
loop join. Since each situation is different, keep a close eye on
the performance execution metrics as different combinations are
tried.
The above book excerpt is from:
High-Performance SQL Server DBA
Tuning & Optimization Secrets
ISBN:
0-9761573-6-5
Robin Schumacher
http://www.rampant-books.com/book_2005_2_sql_server_dba.htm |
