Here are some of the Oracle work often encountered SQL statement optimization:
1, SQL statement as far as possible in uppercase;
Because the oracle is always to parse SQL statements, the lowercase letters converted to uppercase and then executed.
2, select the most efficient sequence table name (only valid in the rule-based optimizer):
ORACLE parser right to left in the order of the processing table in the FROM clause, written in the FROM clause final table (base table driving table) will be processed first, comprising a plurality of tables in the FROM clause under the circumstances, you must select the least number of records as a basis for the table table. If there are three or more connection table queries, it would need to select the cross-table (intersection table) as a base table, cross table refers to the table that is referenced by other tables.
3, WHERE clause join order:
ORACLE using bottom-up parsing WHERE clause, according to this principle, the connection between the tables must be written in other
Before WHERE condition, which can filter out the maximum number of records of conditions must be written at the end of the WHERE clause
4, using the alias table:
When connecting a plurality of tables in the SQL statement, as far as possible and to use the alias table alias prefix on each column. Thus,
It can reduce resolution time and reduce those grammatical errors caused by the column ambiguity.
5, the SELECT clause is to avoid the use '*':
ORACLE in parsing process, will '*' in turn is converted to all column names, this work is done by querying the data dictionary, which means more time consuming
6, using the DECODE function to reduce processing time:
DECODE function using repeated scans of the same recording or avoid repeating the same connection table.
7, integrating simple unrelated database access
If there are a few simple database queries, you can put them into a single query (even if there is no relationship between them), in order to reduce the overhead of database IO than the.
While such an approach, efficiency is improved, but the readability is greatly reduced, so we should weigh the pros and cons between.
8, where instead of having to use
where statements are statements before the group by screening records, and is then filtered having all kinds of records after the screening, then the screening is to say after having clause is to extract the data in the database. Thus possible to use the data in the where clause is filtered prior to screening, thus, the order should be executed as follows
1 Data Use the where clause to find qualified
Use group by clause 2 data packets
Calcd 3 run aggregate function for each group based on the group by group
9, replacement with (UNION) OR UNION ALL (applicable to index column)
Normally, the replacement of the WHERE clause OR UNION will play with good results using OR indexed column will result in a full table scan.
Note the above rules are only valid for multiple column indexes. If there is no column index, query efficiency may be because you have no choice OR
reduced. in the example below, the indexes are built on LOC_ID and REGION.
If you insist on using OR, it would need a minimum of records returned index column written at the top.
code is as follows:
high: the SELECT LOC_ID, LOC_DESC, the WHERE LOC_ID the REGION the FROM LOCATION = 10 the UNION ALL
the SELECT LOC_ID, LOC_DESC, the WHERE the REGION the REGION the FROM LOCATION = "MELBOURNE"
low efficiency: the SELECT LOC_ID, LOC_DESC, the WHERE LOC_ID the REGION the FROM LOCATION the REGION = 10 OR =
"MELBOURNE"
10, replaced by UNION-ALL UNION (if possible):
when the SQL statement required when two UNION query result set, these two result sets are combined in a manner UNION-ALL, then the output of the most
performed before the final result Sort If replace UNION by UNION ALL, so ordering is not necessary. Therefore, the efficiency will be improved. needs
to be noted that, UNION ALL will repeat the same output record set two results, so you should start with the business needs analysis use
the feasibility of UNION ALL. UNION result set will sort this operation will be used to SORT_AREA_SIZE this memory for this
memory optimization is also very important.
11, Order By statement is added to the index column, preferably the primary key PK.
Code is as follows:
the SELECT DEPT_CODE the DEPT the ORDER BY DEPT_TYPE the FROM (inefficient)
the SELECT DEPT_CODE the DEPT the ORDER BY DEPT_CODE the FROM (high)
12, avoid the use of resource-intensive operations:
SQL statement with DISTINCT, UNION, MINUS, INTERSECT sort of starts to perform resource-intensive SQL engine (SORT) function.
DISTINCT requires a sorting operation, while others need to be performed at least twice to sort typically, with a UNION, MINUS, INTERSECT
SQL statements can be rewritten in other ways. If SORT_AREA_SIZE deploy your database well, using UNION, MINUS,
INTERSECT can be considered, after all, they are very readable
13. Generally speaking, if the statement can avoid the use of sub-queries, we try to do sub-queries. Because the cost of sub-query is quite expensive
14, with alternative EXISTS IN
In many queries based on the underlying table in order to satisfy a condition, often you need to join another table. In this case, use EXISTS (or NOT EXISTS) usually will improve the efficiency of the query.
Inefficient:
SELECT * FROM EMP (base table)
the WHERE the EMPNO> 0
the AND the DEPTNO the IN (the SELECT the DEPTNO
the FROM the DEPT
the WHERE the LOC = 'MELB')
Efficient:
SELECT * FROM EMP (基础表)
WHERE EMPNO > 0
AND EXISTS (SELECT ‘X’
FROM DEPT
WHERE DEPT.DEPTNO = EMP.DEPTNO
AND LOC = ‘MELB’)
15. Alternatively NOT IN with NOT EXISTS
In sub-query, NOT IN clause will perform an internal sort and merge, sub-query execution table in a full table traverse is therefore very inefficient.
To avoid using NOT IN, it can be rewritten to the outer connector (Outer Joins) or NOT EXISTS.
Inefficient:
SELECT …
FROM EMP
WHERE DEPT_NO NOT IN （SELECT DEPT_NO
FROM DEPT
WHERE DEPT_CAT=’A’）
高效：
SELECT ….
FROM EMP E
WHERE NOT EXISTS （SELECT ‘X’
FROM DEPT D
WHERE D.DEPT_NO = E.DEPT_NO
AND DEPT_CAT = ‘A’）
16. Alternatively the connection table EXISTS
In general, by way of the connection table than EXISTS more efficient.
Inefficient:
SELECT ENAME
FROM EMP E
WHERE EXISTS （SELECT ‘X’
FROM DEPT
WHERE DEPT_NO = E.DEPT_NO
AND DEPT_CAT = ‘A’）
高效：
SELECT ENAME
FROM DEPT D，EMP E
WHERE E.DEPT_NO = D.DEPT_NO
AND DEPT_CAT = ‘A’
17. Alternatively DISTINCT with EXISTS
When a query is submitted to multi-table information (such as department table and the Employees table) contains, avoid using DISTINCT in the SELECT clause. Generally consider replaced by EXIST.
EXISTS make queries more quickly, because the RDBMS kernel module in the subquery once the conditions are met, immediately returns the result.
Inefficient:
SELECT DISTINCT DEPT_NO，DEPT_NAME
FROM DEPT D，EMP E
WHERE D.DEPT_NO = E.DEPT_NO
高效：
SELECT DEPT_NO，DEPT_NAME
FROM DEPT D
WHERE EXISTS （SELECT ‘X’
FROM EMP E
WHERE E.DEPT_NO = D.DEPT_NO;
18. improve the efficiency of the index:
(1) Features
Advantages: to improve the efficiency of the primary key uniqueness verification
Consideration: The space is needed to store regular maintenance
Remodeling index:
ALTER INDEX <INDEXNAME> REBUILD <TABLESPACENAME>；
(2) Oracle has two modes to access index
The only scan index (Index Unique Scan)
index range scan (index range scan)
Select (3) of the underlying table
Base table (Driving Table) refers to the first table is accessed (typically accessed at full table scan manner). Depending on the optimizer, SQL statements, select the underlying table is not the same.
If you are using the CBO (COST BASED OPTIMIZER), the optimizer will check the status of the physical size of the SQL statement for each table, index, and then choose the lowest cost execution path.
(Oracle 10g and later)
If you use RBO (RULE BASED OPTIMIZER), and all connection conditions are corresponding to the index, in this case, the underlying table is in the FROM clause in the last column of the table.
(Oracle 10g ago)
Index multiple (4) equality
When the execution path using a plurality of SQL statements may be distributed across a plurality of index tables, ORACLE simultaneously using a plurality of indexes and their records merged at runtime, only valid record retrieved all indexes.
When performed ORACLE selected path level higher than the non-unique index unique index. However, this rule only index columns in the WHERE clause to be effective and relatively constant when. If the index table columns and indexes of other type compared. This clause level optimizer is very low.
If two different tables in the same level of the index will be quoted, FROM clause of the table in order to determine which will be the first to use. FROM clause in the final table of the index will have the highest priority.
If the same table in the same level of two index will be quoted, WHERE clause of the first to be referenced index will have the highest priority.
CBO data depends on the priority to get married table view.
(5) Comparison equality comparison precedence range
There is a non-unique index on DEPTNO, EMP_CAT also has a non-unique index.
The ENAME the SELECT
the FROM the EMP
the WHERE DEPTNO> 20 is
the AND EMP_CAT = 'A';
where only EMP_CAT index is used, then all of the records one by one compared with the DEPTNO execution path following conditions:
TABLE ACCESS BY ROWID ON EMP
INDEX RANGE SCAN ON CAT_IDX
Even unique index, if the comparison done range, which is lower than the priority of the non-unique index in Equation comparison.
(6) the same index column can not be compared with each other, which will enable a full table scan.
Do not use indexes:
SELECT ACCOUNT_NAME, AMOUNT
FROM TRANSACTION
WHERE ACCOUNT_NAME = NVL(:ACC_NAME, ACCOUNT_NAME)
使用索引：
SELECT ACCOUNT_NAME，AMOUNT
from transaction
WHERE ACCOUNT_NAME LIKE NVL(:ACC_NAME, ’%’)
19. java code as little as possible with the connector "+" connection string!
20. Avoid the use of the index columns NOT, <>,! = Typically,
We want to avoid the use of the index columns NOT, NOT occur in the same function and influence on the index column. When ORACLE "encounter" NOT, he will stop using the index instead perform a full table scan.
The use of the index of the column that is where the best conditions index column =
! = Will not use the index, remember, the index can only tell you what exists in the table, but can not tell you what does not exist in the table ..
twenty one. Avoid the use of columns in the index calculation.
WHERE clause, if the index column is a part of the function. The optimizer will not use an index using a full table scan.
For example:
低效：
SELECT … FROM DEPT WHERE SAL * 12 > 25000;
高效:
SELECT … FROM DEPT WHERE SAL > 25000/12;
22. with> = alternate>
高效:
SELECT * FROM EMP WHERE DEPTNO >=4
Inefficient:
the SELECT * the EMP the WHERE DEPTNO the FROM> 3
The difference is that the former will skip to a DBMS DEPT equal to 4 and the latter recording the first positioned recording DEPTNO = 3 and to the first forward scan 3 is larger than the recording DEPT.
23 Recognition 'inefficient execution' SQL statement:
Although SQL optimization on a variety of graphical tools endless, but to write their own SQL tools to solve a problem is always the best way:
SELECT EXECUTIONS , DISK_READS, BUFFER_GETS,
ROUND((BUFFER_GETS-DISK_READS)/BUFFER_GETS,2) Hit_radio,
ROUND(DISK_READS/EXECUTIONS,2) Reads_per_run,
SQL_TEXT
FROM V$SQLAREA
WHERE EXECUTIONS>0
AND BUFFER_GETS > 0
AND (BUFFER_GETS-DISK_READS)/BUFFER_GETS < 0.8
--and PARSING_SCHEMA_NAME = 'YYII_S6MISM'
ORDER BY 4 DESC;
24. Avoid using IS NULL and IS NOT NULL index columns
Avoid using anything that can be empty columns in the index, ORACLE will not be able to use the index. For single index, if the column contains a null value, this record does not exist in the index. For the composite index, if each column is empty, the same index is not present in this record. If there is at least one column is not empty, then the record is present in the index. Example: If the unique index based on column A and column B of the table, and there is a record of the A, B value (123, null) table, ORACLE will not accept the same one of A, B (123, null) record (insert). However, if all index columns are empty, ORACLE will think the whole key is empty and empty does not mean empty, so you can insert 1000 records with the same key, of course, they are empty ! because null values do not exist in the index column, so the WHERE clause for indexed columns allow null values compare to disable the index ORACLE.
Inefficient: (Index failure)
the SELECT * the FROM the DEPARTMENT the WHERE DEPT_CODE the IS the NOT NULL;
Efficient: (effective index)
the SELECT * the DEPARTMENT the WHERE DEPT_CODE the FROM> = 0;
25. avoid changing the index column type:
When comparing data of different data types, the column automatically ORACLE simple type conversion.
Suppose EMPNO index is a value type column.
The SELECT ... the FROM the EMP the WHERE EMPNO = '123'
In fact, through conversion type ORACLE, statements into :
SELECT ... FROM EMP the WHERE the EMPNO = the TO_NUMBER ( '123')
. Fortunately, the type of conversion does not occur in the index column, the use of the index is not changed
. now suppose EMP_TYPE is a character type of the index columns
SELECT ... FROM EMP WHERE EMP_TYPE = 123
this statement is converted to ORACLE:
the SELECT ... from EMP WHERETO_NUMBER (EMP_TYPE) = 123
because the internal type conversion occurs, the index will not be used to avoid your SQL ORACLE implicit type conversions! best to use explicit type conversions exhibited. Note that when the character and numerical comparison, ORACLE preferentially converted to numeric type character type
26. If the retrieved data amount more than 30% of the number of records in the table using the index will not significantly improve the efficiency.
b. Under certain circumstances, using an index scan might be slower than the full table, but this is on the same order of magnitude difference. And under normal circumstances, use the index than the full table scan to block several times and even thousands of times!
27. The analysis of the SQL statement with Explain Plan
EXPLAIN PLAN is an excellent analysis tool SQL statement, it can even analyze statements without execution of SQL. Through analysis, we can know is how to connect ORACLE table, what is scanned using a table (or full index scan table scan) and the use of the index names.
28. The optimization of the UNION
Since UNION query results will be sorted, filtered and duplicate records, so its efficiency is not high UNION ALL. SORT_AREA_SIZE UNION operation to the memory block will be used, and therefore is also important for the optimization of this memory.
You can use the following SQL query to sort consumption:
select *
from V$SYSSTAT
where name like 'sort%'
29. A connecting a plurality of scan
If a column and a limited set of values, the optimizer may perform multiple scans and the results are combined connector.
For example:
* The SELECT
the FROM LODGING
the WHERE MANAGER the IN ( 'BILL GATES', 'KEN MULLER')
optimization may be converted into the following form:
SELECT *
FROM LODGING
WHERE MANAGER = ‘BILL GATES’
OR MANAGER = ’KEN MULLER’
30. Use Date
When a date, if the note was added to a decimal date more than 5, the date will proceeds to the next day!
SELECT the TO_DATE ( '20,010,101', 'YYYYMMDD') + 0.99999
from the DUAL;
Returns:
02- January -01
select TO_DATE('20010101','yyyymmdd')+0.999995
from DUAL;
RETURNS：
02-1月 -01
31. Use cursor displayed (CURSORS)
Using implicit cursors will perform two operations. First retrieval record, a second inspection TOO MANY ROWS this exception. The explicit cursor does not perform the second operation.
32. optimization EXPORT and IMPORT
Using larger the BUFFER (such as 10MB, 10,240,000) can improve the speed of EXPORT and IMPORT.
ORACLE will get as much as possible you specify memory size, even if memory is not met, it will not complain. This value is at least the largest and table columns rather Otherwise, the column value will be truncated.
Translator's note:
To be sure, the increase BUFFER will greatly improve EXPORT, IMPORT efficiency. ( Ever come across a CASE, increase BUFFER later, IMPORT / EXPORT faster 10 times!)
The author may have made a mistake: " The value in the table and at least the largest column rather, otherwise the column value will be truncated."
Perhaps the largest of the column is the maximum record size.
33. The separating table and index
Always build your tables and indexes in different table space (TABLESPACES).
Never use an object does not belong to ORACLE stored in the internal system of the SYSTEM table space.
Ensure that the data table space and index table space on separate hard drives.