Beginning SQL

Tuning Tips
The following list contains some helpful database tuning tips:
Database Tuning
❑ Reduce the amount of data pulled. Avoid using SELECT * queries; instead pull exactly and only
the fields that you need. It is very easy to get lazy and use the asterisk (*), figuring that as new
columns are needed they will already be there and the query will not have to be revisited.
Although this is true, you are also forcing the DBMS to retrieve data that will never be used,
flushing useful data out of caches, loading the network with data that will never be used, and
burdening the workstation with unused data.
❑ Think carefully before creating new indexes, particularly indexes on columns other than primary
keys or foreign keys. Indexes may negatively impact other areas of the application.
Unfortunately, if you work in a large database with other developers, you cannot simply delete
indexes, even if you created them, since you can never be sure that queries you didn’t create
don’t use the index you did create to good effect.
❑ Watch for filter redundancy, conditions where a filter on one column guarantees values in a different
column. This problem is not uncommon and often occurs where a single condition did
not provide a narrow-enough match, so a second or even third condition was added to the filter.
❑ WHERE conditions such as NOT NULL may cause the optimizer to assume that the number of
rows matched will be too large to be useful. Remember that optimizers try to look at the entire
query and figure out how to minimize the work required to return the data. Particularly if you
have a lot of filter conditions, the optimizer may simply ignore some of the conditions if the filter
in that condition is too broad.
❑ Use pattern matching judiciously. LIKE COL% is a valid WHERE condition, reducing the returned
set to only those records with data starting with the string COL. However, COL%Y does not further
reduce the returned results set since %Y cannot be effectively evaluated; the effort to do the
evaluation is too large to be considered. In this case, the COL% is used, but the %Y is thrown
away. For the same reason, a leading wildcard %COL effectively prevents the entire filter from
being used.
❑ Avoid number-to-character conversions with pattern matching, particularly with the < and >
operator. Numbers and characters compare differently and can lead to odd behaviors.
❑ The “not equal” operators can cause the optimizer to throw out the WHERE condition since it
may consider the range of values returned to be too broad to be useful.
❑ Be very careful of equality operators with real numbers and date/time values. Both of these can
have small differences that are not obvious to the eye but that make an exact match impossible,
thus preventing your queries from ever returning rows.
❑ Cartesian joins are actually a non-join — where two tables are selected, but no join is specified.
The result of Cartesian joins is that a row is returned for the product of the two tables — one row
for each row in the first table and one row for each row in the second table. If each table has 10
rows, 100 rows are returned. If each table has 100 rows, 10,000 rows are returned. Such queries
are occasionally useful but are most often a simple mistake in syntax. Luckily, they are usually
easy to spot since the results set has far more records than expected or processes very slowly.
This assumes that the results set ever comes back, of course. If the two tables are large, the
results set can be so huge that the query simply can’t complete in a reasonable time. The DBMS
may very well time out the query.
363