1.Always use the where clause in your select statement to narrow the number of rows returned.
If we don’t use a where clause, the Oracle performs a full table scan on our table and returns all of the rows.

2. Use EXISTS clause instead of IN clause as it is more efficient than IN and performs faster.
Ex:

Replace

SELECT * FROM DEPT WHERE DEPTNO IN

(SELECT DEPTNO FROM EMP E)

With

SELECT * FROM DEPT D WHERE EXISTS

(SELECT 1 FROM EMP E WHERE D.DEPTNO = E.DEPTNO)

Note: IN checks all rows. Only use IN if the table in the sub-query is extremely small.

3.When you have a choice of using the IN or the BETWEEN clauses in your SQL, use the BETWEEN clause as it is much more efficient than IN.
Depending on the range of numbers in a BETWEEN, the optimizer will choose to do a full table scan or use the index.

4.Avoid WHERE clauses that are non-sargable. Non-sargable search arguments in the WHERE clause, such as “IS NULL”, “OR”, “<>”, “!=”, “!>”, “!<”, “NOT”, “NOT EXISTS”, “NOT IN”, “NOT LIKE”, and “LIKE %500″ can prevent the query optimizer from using an index to perform a search. In addition, expressions that include a function on a column, or expressions that have the same column on both sides of the operator, are not sargable.

Convert multiple OR clauses to UNION ALL.

5. Use equijoins. It is better if you use with indexed column joins. For maximum performance when joining two or more tables, the indexes on the columns to be joined should have the same data type.

6. Avoid a full-table scan if it is more efficient to get the required rows through an index. It decides full table scan if it has to read more than 5% of the table data (for large tables).
7. Avoid using an index that fetches 10,000 rows from the driving table if you could instead use another index that fetches 100 rows and choose selective indexes.
8. Indexes can’t be used when Oracle is forced to perform implicit datatype conversion.
9. Choose the join order so you will join fewer rows to tables later in the join order.
l use smaller table as driving table

l have first join discard most rows

10. Set up the driving table to be the one containing the filter condition that eliminates the highest percentage of the table.
11. In a where clause (or having clause), constants or bind variables should always be on the right hand side of the operator.

12. Do not use SQL functions in predicate clauses or WHERE clauses or on indexed columns, (e.g. concatenation, substr, decode, rtrim, ltrim etc.) as this prevents the use of the index. Use function based indexes where possible

SELECT * FROM EMP WHERE SUBSTR (ENAME, 1, 3) = ‘KES’ Use the LIKE function instead of SUBSTR ()

13. If you want the index used, don’t perform an operation on the field.
Replace SELECT * FROM EMPLOYEE WHERE SALARY +1000 = :NEWSALARY

With

SELECT * FROM EMPLOYEE WHERE SALARY = :NEWSALARY –1000

14. All SQL statements will be in mixed lower and lower case.All reserve words will be capitalized and all user-supplied objects will be lower case. (Standard)

15. Minimize the use of DISTINCT because it forces a sort operation.
16. Try joins rather than sub-queries which result in implicit joins
Replace SELECT * FROM A WHERE A.CITY IN (SELECT B.CITY FROM B)

With

SELECT A.* FROM A, B WHERE A.CITY = B.CITY

17. Replace Outer Join with Union if both join columns have a unique index:
Replace

SELECT A.CITY, B.CITY FROM A, B WHERE A.STATE=B.STATE (+)

With

SELECT A.CITY, B.CITY FROM A, B WHERE A.STATE=B.STATE

UNION

SELECT NULL, B.CITY FROM B WHERE NOT EXISTS (SELECT ‘X’ FROM A.STATE=B.STATE)

18. Use bind variables in queries passed from the application (PL/SQL) so that the same query can be reused. This avoids parsing.
19. Use Parallel Query and Parallel DML if your system has more than 1 CPU.
20. Match SQL where possible. Applications should use the same SQL statements wherever possible to take advantage of Oracle’s Shared SQL Area. The SQL must match exactly to take advantage of this.

21. No matter how many indexes are created, how much optimization is done to queries or how many caches and buffers are tweaked and tuned if the design of a database is faulty, the performance of the overall system suffers. A good application starts with a good design.

22. The following operations always require a sort:

SELECT DISTINCT SELECT UNIQUE SELECT ….ORDER BY… SELECT….GROUP BY… CREATE INDEX CREATE TABLE…. AS SELECT with primary key specification

Use of INTERSECT, MINUS, and UNION set operators

Unindexed table joins Some correlated sub-queries

SELECT Emp_id FROM Emp_table WHERE Last_Name = ‘Smith’ AND Middle_Initial = ‘K’ AND Gender = ‘Female’;