Operator Optimization
IN operator
Written with the IN SQL advantage is relatively easy to write clear and easy to understand, which is more suitable for modern software development style.
However, the SQL performance with IN is always low, steps from ORACLE to analyze the SQL with IN and not the SQL IN has the following differences:
ORACLE trying to convert it into a plurality of connection tables, if unsuccessful, to perform the conversion IN subquery inside, then the outer query table records, if the conversion is successful direct connection with a plurality of query tables. This shows the SQL with IN at least a plurality of the conversion process. SQL in general can be converted successfully, but contains terms for SQL group statistics can not be converted.
Recommended programs: intensive business which try not to use SQL IN operator.
NOT IN operator
This action is strongly recommended not to use, because it can not apply the index table.
Recommended Program: NOT EXISTS or replaced with (+ external connection determination is empty) Program
<> Operator (not equal)
Is not equal operator is never used in the index, so it will only process a full table scan.
Recommended Program: other operations instead of using the same functions, such as
a<>0 改为 a>0 or a<0
a <> '' to a> ''
IS NULL or IS NOT NULL operation (determine whether the field is blank)
Determine whether the field is empty index is generally not applied, because the index B-tree index is not null.
Recommended programs:
Operations instead of the same with other functions, such as
a is not null to a> 0 or a> '' and so on.
Allowed field is empty, instead of using a default null value, such as expanding application sector status field NOT NULL, the default is to apply.
Bitmap index (with partition table can not be built, bitmap indexes more difficult to control, such as index field values degrades performance too much, people will increase the data block update operation locks the phenomenon)
> And <operators (greater than or less than the operator)
Greater or less than the operator under normal circumstances is not adjusted, the index will be used because it has to find the index, but in some cases it may be optimized, such as a table has one million records, a numeric field A, 30 million record a = 0,30 Wan record a = 1,39 Wan record of a = 2,1 Wan record a = 3. Then the implementation of A> 2 and A> = 3 there is a big difference, because A> 2 Shi ORACLE will first identify the records of the index is then compared, and A> = 3 Shi ORACLE directly to find = 3 records index.
LIKE operator
LIKE operator can be applied to wildcard queries, wildcard combinations which may reach almost any query, but if used well will produce performance problems, such as LIKE '% 5400%' This query does not reference index, and LIKE 'X5400%' will index reference range. A practical example: a business number that follows YW_YHJBQK table query user identification number may be open No. YY_BH LIKE '% 5400%' this condition will have a full table scan, if the change YY_BH LIKE 'X5400%' OR YY_BH LIKE 'B5400% 'index YY_BH the query will use the two ranges, the performance certainly greatly improved.
UNION operator
UNION making table will filter out duplicate links records, so the result set in the table will link the resulting sort operation to remove duplicate records and then returns the result. Most practical applications are no duplicate records, common process table and history table UNION. Such as:
select * from gc_dfys
union
select * from ls_jg_dfys
The SQL at runtime to remove the results of the two tables, and then sort space to sort remove duplicate records, after the return result sets, if the table if a large amount of data may lead to be sorted with the disk.
Recommended Program: The alternative operator UNION ALL UNION, UNION ALL operation as simply merge the two results after return.
select * from gc_dfys
union all
select * from ls_jg_dfys
The impact of writing SQL
SQL Effects of different wording of the same features the same performance
As a SQL programmers to write in A
Select * from zl_yhjbqk
B programmers to write
Select * from dlyx.zl_yhjbqk (prefix table with owner)
C programmers to write
Select * from DLYX.ZLYHJBQK (table name in uppercase)
D programmers to write
Select * from DLYX.ZLYHJBQK (more than the middle box)
More than four in ORACLE SQL analysis result and execution time generated after finishing the same, but from the principle of shared memory ORACLE SGA can be drawn for each SQL ORACLE will be an analysis and take up shared memory, if SQL string will be written exactly the same format and then analyze ORACLE only once, shared memory will only leave once the results of the analysis, which not only can reduce the analysis time SQL, and can reduce the shared memory duplicate information, ORACLE also SQL can accurately count the frequency of execution.
WHERE condition behind the impact sequence
Sequence behind the WHERE clause conditions have a direct impact on large scale data query, such as
Select * from zl_yhjbqk where dy_dj = '1KV以下' and xh_bz=1
Select * from zl_yhjbqk where xh_bz=1 and dy_dj = '1KV以下'
In the above two SQL dy_dj dy_dj (voltage level) and xh_bz (cancellation flag) no two fields are indexed, so when a full table scan is performed, the article SQL = '1KV the following' conditions are set within the recording ratio 99%, while the ratio is only xh_bz = 0.5% 99% of the article during the SQL time record and comparing dy_dj xh_bz, and when performing the second SQL 0.5% for all records and dy_dj Compare xh_bz of this can be drawn second SQL CPU utilization rate was significantly lower than the strip.
The impact of the order look-up table
Order of the list in the back of FROM table will affect the performance of SQL execution, will be linked ORACLE table appear in the order in the absence of the index and no table ORACLE statistical analysis of the situation, because the order of the table thus will not have a very data server resource consumption intersection. (Note: If the table is a statistical analysis, ORACLE links automatically advanced small table, and then link a large table)
SQL statement using the index
Optimization of the operator (see above section)
Some optimization of field conditions
Treatment functions using field can not use the index, such as:
substr (hbs_bh, 1,4) = '5400', the optimization process: hbs_bh like '5400%'
trunc (sk_rq) = trunc (sysdate), the optimization process:
sk_rq>=trunc(sysdate) and sk_rq<trunc(sysdate+1)
Be explicit or implicit computation of the field can not be indexed, such as:
ss_df + 20> 50, the optimization process: ss_df> 30
'X' || hbs_bh> 'X5400021452', optimization: hbs_bh> '5400021542'
sk_rq + 5 = sysdate, optimization: sk_rq = sysdate-5
hbs_bh = 5401002554, optimization: hbs_bh = '5401002554', Note: this condition of the to_number hbs_bh implicit conversion, because the field is hbs_bh character.
The conditions can not be indexed field comprises a plurality of operation this watch, such as:
ys_df> cx_df, can not be optimized
qc_bh || kh_bh = '5400250000', the optimization process: qc_bh = '5400' and kh_bh = '250000'
ORACLE application of HINT (tips) processing
Prompt treatment is generated SQL in ORACLE under execution path analysis of the words we use are not satisfied with the. It can be prompted with the following aspects of the SQL
Tips objectives:
COST (cost optimization)
RULE (rule-optimization)
CHOOSE (default) (the ORACLE automatically selected to optimize cost or rules)
ALL_ROWS (all rows are returned as soon as possible)
FIRST_ROWS (row data returned as soon as possible)
Tips execution method:
USE_NL (use NESTED LOOPS way joint)
USE_MERGE (using the MERGE JOIN way joint)
USE_HASH (joint use HASH JOIN way)
Index hints:
INDEX (TABLE INDEX) (tips of the index table query)
Other Advanced tips (e.g., parallel processing and the like)