sql tuning tips

7/30/2019 SQL Tuning Tips

1/24

Tuning Tips

Atul Ltd


2/24

Tip 1 Dont perform operation on database

objects referenced in the where clause.

Oracle will ignore the indexes definedon columns


3/24

Tip 1 DO NOT USE

SELECT account_name, trans_date, amount

FROM transactionWHERE SUBSTR(account_name,1,7) = 'CAPITAL';

SELECT account_name, trans_date, amountFROM transactionWHERE account_name = NVL ( :acc_name, account_name);

SELECT account_name, trans_date, amountFROM transactionWHERE TRUNC (trans_date) = TRUNC (SYSDATE);


4/24

Tip 1 DO NOT USE

SELECT account_name, trans_date, amountFROM transactionWHERE account_name || account_type = 'AMEXA';

SELECT account_name, trans_date, amountFROM transactionWHERE amount + 3000 < 5000;

SELECT account_name, trans_date, amountFROM transaction

WHERE amount != 0;

SELECT account_name, trans_date, amountFROM transactionWHERE amount NOT = 0;


5/24

Tip 1 USE


WHERE account_name LIKE 'CAPITAL%';

SELECT account_name, trans_date, amountFROM transactionWHERE account_name LIKE NVL ( :acc_name, '%');

SELECT account_name, trans_date, amountFROM transactionWHERE trans_date BETWEEN TRUNC (SYSDATE) AND TRUNC

(SYSDATE) + .99999;


6/24

Tip 1 USE


WHERE account_name = 'AMEX'AND account_type = 'A';

SELECT account_name, trans_date, amountFROM transactionWHERE amount < 2000;

SELECT account_name, trans_date, amountFROM transactionWHERE amount > 0;

SELECT account_name, trans_date, amountFROM transactionWHERE amount > 0;


7/24

Tip 2Try not to useHAVING

clause in the select statements. HAVINGclause will filter records only after fetching allrows. Using WHERE clause helps reducingoverhead in sorting, summing etc. HAVING

clauses should only be used when columnswith summary operations applied to them arerestricted by the clause.


8/24

Tip 2 DO NOT USE

SELECT region, AVG (loc_size)

FROM location

GROUP BY region

HAVING region != 'SYDNEY'

AND region != 'PERTH';


9/24

Tip 2 USE

SELECT region, AVG (loc_size)

FROM location

WHERE region != 'SYDNEY'

AND region != 'PERTH';

GROUP BY region;


10/24

Tip 3 Minimize the number of table lookups

(subquery blocks) in queries,

particularly if statements includesubquery SELECTs or multicolumnUPDATEs. Avoid using subqueries when

a JOIN will do the job.


11/24

Tip 3DO NOT USE

Separate SubqueriesSELECT emp_nameFROM empWHERE emp_cat = (SELECT MAX (category) FROM

emp_categories)AND emp_range = (SELECT MAX(sal_range)FROM emp_categories)

AND emp_dept = 0020;


12/24

Tip 3 USECombined Subqueries

SELECT emp_nameFROM emp

WHERE (emp_cat, sal_range) =

(SELECT MAX (category), MAX (sal_range)FROM emp_categories)

AND emp_dept = 0020;


13/24

Tip 4Consider the alternatives

EXISTS, IN and table joins

when doing multiple table joins. None of these are consistentlyfaster; it depends on the volume of data.

If the outer query is "big" and the inner query is "small",

"IN"

is generally more

efficient.


14/24

Tip 4select count(subobject_name)

from big

where object_id in ( select object_id from small)

versus

select count(subobject_name)

from big

where exists ( select null from small wheresmall.object_id = big.object_id )


15/24

Tip 4If the outer query is "small" and the inner query is "big""WHERE EXISTS"can be quite efficient.

select count(subobject_name)from smallwhere object_id in ( select object_id from big )

versus:select count(subobject_name)

from smallwhere exists ( select null from big where small.object_id =big.object_id )


16/24

Tip 5

Avoid joins that require theDISTINCTqualifier on the SELECT list in queries which are used

to determine information at the owner end of aone-to-many relationship. The DISTINCT operator

causes Oracle to fetch all rows satisfying the tablejoin and then sort and filter out duplicate values.

EXISTS

is a faster alternative, because the Oracle optimizerrealizes when the subquery has been satisfied once,there is no need to proceed further and the nextmatching row can be fetched.


17/24

Tip 5

DO NOT USE

SELECT DISTINCT dept_no, dept_name

FROM dept d, emp e

WHERE d.dept_no = e.dept_no;


18/24

Tip 5

USE

SELECT dept_no, dept_name

FROM dept d

WHERE EXISTS (SELECT 'X'

FROM emp e

WHERE e.dept_no = d.dept_no);


19/24

Tip 6

Consider using

DECODE

to avoid having to scan the same rowsrepetitively or join the same tablerepetitively.


20/24

Tip 6

DO NOT USESELECT COUNT(*)FROM emp

WHERE status = 'Y'AND emp_name LIKE 'SMITH%';

SELECT COUNT(*)FROM empWHERE status = 'N'AND emp_name LIKE 'SMITH%';


21/24

Tip 6

USESELECT COUNT(DECODE(status, 'Y', 'X',

NULL)) Y_count,

COUNT(DECODE(status, 'N', 'X', NULL))N_count

FROM empWHERE emp_name LIKE 'SMITH%';


22/24

Tip 7

Re-write NOT IN and NOT EXISTS subqueriesas outer joins

- In many casesof NOT queries (but ONLY where a column is

defined as NULL), you can re-write theuncorrelated subqueries into outer joins withIS NULL tests. Note that this is a non-correlated sub-query, but it could be re-written as an outer join


23/24

Tip 7

DO NOT USE

SELECT book_key

FROM book

WHERE book_key NOT IN (SELECT book_key FROMsales);

-

SELECT book_key

FROM book

WHERE NOT EXISTS (SELECT book_key FROM sales);


24/24

Tip 7

USESELECT b.book_key

FROM book b, sales s

WHERE b.book_key = s.book_key(+) ANDs.book_key IS NULL;

sql tuning tips

Documents