Oracle SQL Tuning - WHERE Clause:
Beware of WHERE clauses which do not
use indexes at all. Even if there is an index over a column that is referenced by
a WHERE clause included in this section, Oracle will ignore the index. All of
WHERE clauses can be re-written to use an index while returning the same
values. In other words, don't perform operations on database objects referenced
in the WHERE clause.
SELECT
account_name, trans_date, amount |
SELECT
account_name, trans_date, amount |
SELECT
account_name, trans_date, amount |
SELECT
account_name, trans_date, amount |
SELECT
account_name, trans_date, amount |
SELECT
account_name, trans_date, amount |
SELECT
account_name, trans_date, amount |
SELECT
account_name, trans_date, amount |
SELECT
account_name, trans_date, amount |
SELECT
account_name, trans_date, amount |
SELECT
account_name, trans_date, amount |
SELECT
account_name, trans_date, amount |
SELECT
account_name, trans_date, amount |
SELECT
account_name, trans_date, amount |
>>Oracle SQL Tuning - Tuning the views:
Don't forget to tune views. Views are
SELECT statements and can be tuned in just the same way as any other type of
SELECT statement can be. All tuning applicable to any SQL statement are equally
applicable to views.
>>Oracle SQL Tuning - HAVING Clause:
Avoid including a HAVING clause in
SELECT statements. The HAVING clause filters selected rows only after all rows
have been fetched. Using a WHERE clause helps reduce overheads in sorting,
summing, etc. HAVING clauses should only be used when columns with summary
operations applied to them are restricted by the clause.
Using HAVING Clause |
Not Using HAVING Clause |
SELECT
region, AVG (loc_size) |
SELECT
region, AVG (loc_size) |
>>Oracle SQL Tuning - Table Lookups:
Minimize the number of table lookups
(subquery blocks) in queries, particularly if your statements include subquery
SELECTs or multicolumn UPDATEs.
Separate Subqueries |
Combined Subqueries |
SELECT
emp_name |
SELECT
emp_name |
>>Oracle SQL Tuning - Multiple Table Joins:
Consider the alternatives like
EXISTS, IN and table joins when doing multiple table joins. None of these are
consistently faster; it depends on your data. If there is a poor performer
here, it's likely the IN clause. This query returns the employee names from
each department in department category 'A'.
EXISTS |
IN |
Table Joins |
SELECT
emp_name |
SELECT
emp_name |
SELECT
emp_name |
>>Oracle
SQL Tuning - DISTINCT vs. EXISTS:
Avoid joins that require the
DISTINCT qualifier on the SELECT list in queries which are used to determine
information at the owner end of a one-to-many relationship. The DISTINCT
operator causes Oracle to fetch all rows satisfying the table join and then
sort and filter out duplicate values. EXISTS is a faster alternative, because
the Oracle optimizer realizes when the subquery has been satisfied once, there
is no need to proceed further and the next matching row can be fetched.
Below query returns all department numbers and names which have at least one
employee.
SELECT
DISTINCT dept_no, dept_name |
>>Oracle SQL Tuning - UNION ALL:
Consider whether a UNION ALL will be
adequate in place of a UNION . The UNION clause forces all rows returned by
each portion of the UNION to be sorted and merged and duplicate to be filtered
before the first row is returned. A UNION ALL simply returns all rows including
duplicates and does not have to perform any sort, merge or filter. If your
tables include no duplicate records, or you don't care if duplicates are returned,
the UNION ALL is much more efficient.
UNION |
UNION ALL |
SELECT
acct_num, balance_amt |
SELECT
acct_num, balance_amt |
>>Oracle SQL Tuning - DECODE:
Consider using DECODE to avoid
having to scan the same rows repetitively or join the same table repetitively.
DECODE is not necessarily faster as it depends on your data and the complexity
of the resulting query. Also, using DECODE requires you to change your code
when new values are allowed in the field.
SELECT
COUNT (*) |
SELECT
COUNT (*) |
>>Oracle SQL Tuning - Casting:
Oracle automatically performs casting or
simple column type conversions when it compares columns of different types.
Depending on the type of conversion, indexes may not be used. Make sure you
declare your program variables as the same type as your Oracle columns, if the
type is supported in the programming language you are using.
No comments:
Post a Comment