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.
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.
Copyright:
Attribution Non-Commercial (BY-NC)
Available Formats
Download as DOC, PDF, TXT or read online from Scribd
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.
Copyright:
Attribution Non-Commercial (BY-NC)
Available Formats
Download as DOC, PDF, TXT or read online from Scribd
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.