As you write
SQL statements to access DB2 data, there are certain very simple, yet important
rules to follow to encourage efficient SQL. Of course, SQL performance is a
complex topic and to understand every nuance of how SQL performs can take a
lifetime to master. That being said, adhering to the following simple rules
puts you on the right track to achieving high-performing DB2 applications.
The first rule
is to always provide only the exact columns that you need to
retrieve in the SELECT-list of each SQL SELECT statement. Sometimes this is
shortened to “do not use SELECT *”. The shorthand SELECT * means retrieve all
columns from the table(s) being accessed. This is fine for quick and dirty
queries but is bad practice for inclusion in application programs because DB2
tables may need to be changed in the future to include additional columns.
SELECT * will retrieve those new columns, too, and your program may not be
capable of handling the additional data without requiring time-consuming
changes.
Even if the program needs every column, it is better to explicitly ask
for each column by name in the SQL statement for clarity and to avoid accessing
new and unwanted columns.
DB2 consumes
additional resources for every column you specify to be returned. If the
program does not need the data, it should not ask for it.
The second part
of asking only for what you need is using the WHERE clause to filter data
in the SQL instead of bringing it all into your program. This is a common
rookie mistake. It is much better for DB2 to filter the data before returning
it to your program. This is true because DB2 uses additional I/O and CPU
resources to obtain each row of data. The fewer rows passed to your program,
the more efficient your SQL will be. So, the following SQL
SELECT
EMPNO, LASTNAME, SALARY
FROM
EMP
WHERE
SALARY > 50000.00;
Is better than
simply reading all of the data without the WHERE clause and then checking each
row to see if the SALARY is greater than 50000.00 in your program.
No comments:
Post a Comment