Top 10 tips for SQL performance on

DB2
1.

Select only that which you need. Avoid SELECT *, opting instead for specifying the
smallest number of columns that will meet your needs.

Each returned column has an overhead that is multiplied

by the number of rows
o
If there are too many columns then index-only access will
not be an option
Lock not, lest ye be locked. Specify FOR READ ONLY and
WITH UR if these restrictions meet your needs they will reduce
locking
o
Even if you dont see errors due to locking, you may still
impact performance time not just of this query, but of other
queries
Avoid functions and conversions when possible CHAR,
UPPER, etc. These will limit the use of indexes.
o
The most important place to do this is on the join
predicates and remember that join predicates include those
not using the join keyword. Using functions or even
expressions in join predicates also limits the join method to
Nested Loop and may produce inaccurate results
o
The second most important place to do this is in the
where clause
o
This may also be useful in the column list, depending
on circumstances
Avoid Sorts. Some sorts are expensive avoid them
where possible. Large sorts may spill from memory to disk,
drastically impacting their performance.
Avoid DISTINCT and ORDER BY when possible
o
These often require sorts, and sorts are frequently time
eaters
o

A GROUP BY may be a better choice than DISTINCT

In-lists are out. Avoid the use of IN lists where possible
o
Multiple smaller queries may be more efficient
Ensure you are specifying the appropriate join predicates
to avoid Cartesian joins. This may seem obvious, but a really bad
query can actually cause a database to be unresponsive to other
users something you want to avoid, especially in production.
Play fetch with as few sticks as possible. If using the
FETCH FIRST N ROWS ONLY clause, include the OPTIMIZE FOR N
ROWS clause.
o
Strangely enough, DB2 does not handle this for you.
To parameter or not to parameter. Consider where to pass
in specific values
o
If Parameter Markers are used, DB2 does not make use of
distribution statistics
o
If Parameter Markers are not used, then DB2 re-calculates
the access plan every time you run the query
o
Balance the reduced preparation time with the
performance advantaged gained by the use of statistics this
is especially important when your data is not distributed in a
normal fashion.
Consider using temporary tables for repeatedly accessed
data. Ive actually seen the same stored procedure called 3 times
with the same parameters in a single query, and being one that
determines the distance from nearby stores, it was an expensive
one. Storing such data in a temporary table before executing the
query might be a good idea.
o