1. Any statement optimizer that uses is null or is not null in the where clause is not allowed to use indexes. Because only the field has a null value, even if an index is created, it
is useless, so creating an index should be created on a field with a value;
2. The sql statement will not use the index: select * from employee where last_name like '%cliton%';
in this case, the index will be used: select * from employee where last_name like 'cliton%';
3. Order by statement
The ORDER BY statement determines how Oracle sorts the returned query results. The Order by statement has no special restrictions on the columns to be sorted, and functions can also be added to the columns (such as joins or
appends). Any non-indexed items or calculated expressions in the Order by statement will slow down the query. Carefully examine the order by statement for non-indexed items or expressions that
can degrade performance. The solution to this problem is to rewrite the order by statement to use an index, or you can create another index for the column used, and you should absolutely avoid
using expressions in the order by clause.
4. Choose the most efficient table name order (only valid in the rule-based optimizer):
ORACLE's parser processes the table names in the FROM clause from right to left, and the FROM clause is written at the end The table (the base table driving table) will be processed first. In
the case of multiple tables included in the FROM clause, you must select the table with the fewest records as the base table. If there are more than 3 tables to join the query, then you need to select the intersection
table as the base table, and the intersection table refers to the table that is referenced by other tables.
5. Avoid using '*' in the SELECT clause:
During the parsing process, ORACLE will convert '*' into all column names in turn. This work is done by querying the data dictionary, which means that it will cost more time
6. Reduce the number of accesses to the database. It is best to use a single statement to query directly. Consolidate simple, unrelated database access:
If you have several simple database queries, you can combine them into one query (even if they are not related)
7. Improve SQL efficiency through internal functions.: Complex SQL often sacrifices execution efficiency. It is very meaningful to be able to master the above methods of using functions to solve problems in practical work
8. Use table aliases (Alias):
When connecting multiple tables in an SQL statement, please use table aliases and prefix each Column with the alias name. In this way, you can reduce parsing time and reduce those caused by
Syntax error caused by Column ambiguity .
9. Use EXISTS instead of IN and NOT EXISTS instead of NOT IN:
In many queries based on the underlying table, in order to satisfy a condition, it is often necessary to join another table. In this case, use EXISTS (or NOT EXISTS) Usually will improve the
efficiency of the query. In a subquery, the NOT IN clause will perform an internal sort and merge. In either case, NOT IN is the least efficient (because it performs an internal sort and merge on the tables in the subquery A
full table traversal). To avoid using NOT IN, we can rewrite it as Outer Joins or NOT EXISTS.
Example:
(inefficient) select * from z_shangbiao u where u.ann_nnum!='' and u. ann_nnum in( select e.user_account FROM t_evaluation e)
(efficient) select * from t_user u where u.account!='' and EXISTS( select e.user_account FROM t_evaluation e where
u.account=e.user_account)
10. Use indexes to improve efficiency: Although the use of indexes can improve query efficiency, we must also pay attention to its cost. Indexes require space for storage and regular maintenance,
whenever records are added or removed in the table or indexed columns When modified, the index itself is also modified. This means that INSERT , DELETE , UPDATE for each record will cost 4 or 5 more
disk I/Os for this. Because indexes require additional storage space and processing, those Unnecessary indexes can actually slow down query response time. Periodically rebuilding the index is necessary.:
11. Replace DISTINCT with EXISTS:
When submitting a query that contains one-to-many table information (such as a department table and an employee table), avoid using DISTINCT in the SELECT clause. You can generally consider replacing it with EXIST, EXISTS makes the
query more Fast, because the RDBMS core module will return the result as soon as the conditions of the subquery are met. Example:
(inefficient):
SELECT DISTINCT DEPT_NO,DEPT_NAME FROM DEPT D , EMP E WHERE D.DEPT_NO = E.DEPT_NO
(efficient):
SELECT DEPT_NO,DEPT_NAME FROM DEPT D WHERE EXISTS ( SELECT 'X' FROM EMP E WHERE E.DEPT_NO = D.DEPT_NO);
12. Use uppercase for sql statements; because Oracle always parses sql statements first, converts lowercase letters to uppercase, and then executes them
13. Avoid using calculations on indexed columns.
In the WHERE clause, if the indexed column is part of the function. The optimizer will use full table scans instead of indexes.
Example:
Inefficient:
SELECT … FROM DEPT WHERE SAL * 12 > 25000;
Efficient:
SELECT … FROM DEPT WHERE SAL > 25000/12;
14. Use >= instead of >
Efficient:
SELECT * FROM EMP WHERE DEPTNO >= 4
Inefficient:
SELECT * FROM EMP WHERE DEPTNO >3
15. Replacing OR with UNION (applicable to index columns)
Normally, replacing OR in the WHERE clause with UNION will have better results. Using OR on index columns will cause a full table scan. Note that the above rules only Effective for multiple indexed columns.
If there are columns that are not indexed, the query efficiency may be reduced because you do not select OR. In the following example, indexes are built on both LOC_ID and REGION.
Efficient:
SELECT LOC_ID , LOC_DESC , REGION
FROM LOCATION
WHERE LOC_ID = 10
UNION
SELECT LOC_ID , LOC_DESC , REGION
FROM LOCATION
WHERE REGION = "MELBOURNE"
Inefficient:
SELECT LOC_ID , LOC_DESC , REGION
FROM LOCATION
WHERE LOC_ID = 10 OR REGION = "MELBOURNE"
If you insist on using OR, then The index column that needs to return the fewest records is written first.
16. Always use the first column of the index:
If the index is built on multiple columns, the optimizer will choose to use the index only if its first column (leading column) is referenced by the where clause. This is also a simple and important
rule. When only the second column of the index is referenced, the optimizer uses a full table scan and ignores the index
. Example: For example, if you create an index (account, age, classno), the three fields are index, then when using where in your SQL statement, you should use account first, and then you can use the
index. If the first condition of your where is age or classno, then a full table search will be performed, ignoring the index.
17. Replace UNION with UNION-ALL (if possible):
When a SQL statement needs to UNION two query result sets, the two result sets are merged in a UNION-ALL manner, and then sorted before outputting the final result . If UNION
ALL is used instead of UNION, then sorting is not necessary. Efficiency will be improved. It should be noted that UNION ALL will repeatedly output the same records in the two result sets. Therefore,
you still need to use it from business requirements analysis. The feasibility of UNION ALL. UNION will sort the result set, and this operation will use the SORT_AREA_SIZE memory. The optimization of this memory is
also very important. The following SQL can be used to query the sorting cost
inefficient:
SELECT ACCT_NUM , BALANCE_AMT
FROM DEBIT_TRANSACTIONS
WHERE TRAN_DATE = '31-DEC-95'
UNION
SELECT ACCT_NUM, BALANCE_AMT FROM
DEBIT_TRANSACTIONS WHERE TRAN_DATE
= '31
-DEC -95' ALL SELECT ACCT_NUM, BALANCE_AMT
FROM DEBIT_TRANSACTIONS
WHERE TRAN_DATE = ’31-DEC-95′
18. Avoid changing the type of the index column.
For example, the age field is int, and then you write where age='13' when you query. Although the query results are the same, the efficiency will be reduced, because the database does more work operation
, automatically perform TO_NUMBER('123') processing on character 123
19. WHERE clauses to watch out for: WHERE clauses
in some SELECT statements do not use indexes. Here are some examples.
In the following example, (1)'!=' will not use indexes. Remember, indexes only can tell you what is in the table, but not what is not in the table. (2) '||' is a character
concatenation function. Like other functions, indexing is disabled. (3) '+' is Mathematical functions. Like other mathematical functions, indexes are disabled. (4) Identical indexed columns cannot be compared to each other,
which will enable a full table scan.
20. Optimize GROUP BY, try to use where instead of having: To
improve the efficiency of GROUP BY statements, you can filter out unnecessary records before GROUP BY. The following two queries return the same results but the second one is obviously much faster.
Inefficient:
SELECT JOB , AVG(SAL)
FROM EMP
GROUP by JOB
HAVING JOB = 'PRESIDENT'
OR JOB = 'MANAGER'
Efficient:
SELECT JOB , AVG(SAL)
FROM EMP
WHERE JOB = 'PRESIDENT'
OR JOB = 'MANAGER'
GROUP by JOB
21. Don't use SELECT *
This is not easy to do. However, if you specify the columns you need in the SELECT, it will bring the following benefits:
1. Reduce memory consumption and network bandwidth.
2. You can get a more secure design.
3. Give the query optimizer a chance to read from the index all necessary column of
Read this article for reference: http://www.jfox.info/SQL-you-hua.html and then add some of your own understanding. Please correct me if I am wrong (*￣︶￣)