Scribd
Upload
49 views1 page

Tunning Notes

1. Several factors like whitespace, case, bind variables vs constants, and table structure impact query performance. 2. For small tables, a full table scan may be faster than an index. Large queries returning over 5-20% of rows are also often faster with a full table scan. 3. The optimizer settings can be configured at the instance, session, and query levels to influence the execution plan choice.

Uploaded by

gr8ajay
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
49 views1 page

Tunning Notes

1. Several factors like whitespace, case, bind variables vs constants, and table structure impact query performance. 2. For small tables, a full table scan may be faster than an index. Large queries returning over 5-20% of rows are also often faster with a full table scan. 3. The optimizer settings can be configured at the instance, session, and query levels to influence the execution plan choice.

Uploaded by

gr8ajay
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 1

1. Whitespace, case, bind variables vs. constants all matter.

2. Small tables may be faster with a table scan.


3. Queries returning a large number (> 5-20%) of the rows in the table may be faster
with a table scan.
4. Must use the leading column(s) of the index for the index to be used.
5. Using a function, calculation, or other operation on an indexed column disables the
use of the Index.
6. Using NOT with indexed columns in where clause excludes the use of index.
7. Optimizer setting can be done at three levels
Instance level: - Optimizer_mode
Session level: - Alter session set Optimizer_mode
Query Level: - Use Hints (/*+ ….. */)
8. Specify the driving table last in the FROM Clause.
9. When joining 3 or more tables, use the Intersection table (with the most shared
columns) as the driving table.
10. Specify first those conditions in where clause which discards the maximum
numbers of rows.
11. When using an "AND" subquery, place it first, it will use less CPU time (70%).
12. When using an "OR" subquery, place it last, it will use less CPU time (50%)
13. When Joining and Filtering, specify the all Filter condition first, Joins last.
14. Use ‘EXISTS’ instead of ‘IN’ in subqueries, IN scans both tables where as EXISTS
scans outer table only.
15. Use Join instead of Subquery. Subquery scans both tables where as Join uses
one table and uses index for other.
16. EXISTS: better than Join if the number of matching rows in table in subquery is
small.
17. Join: better than EXISTS if the number of matching rows in table in subquery is
large.
18. Use UNION ALL instead of UNION if there are no duplicate rows (or if you don't
mind duplicates).
19.

You might also like