1. The conditions imposed on the line without any return, i.e., no where clause
2. And the data is not any index table corresponding to the main column line qualification
for example: the City-State-Zip create three columns composite index, then only the State column conditions can not use this index is defined as the index is not the primary column State .
3. There are conditions defining the main column of the index, but using the following conditional expressions in the expression index will fail, resulting in a full table scan:
(. 1) WHERE clause is a function for the field, expression operations, which will cause the engine give up using the index and a full table scan,
Demo:
WHERE Upper (City) = 'TOKYO' || or City 'X-' like 'TOKYO%',
SELECT ID WHERE NUM from T / 2 = 100 should be changed to: select id from WHERE NUM = 100 * T 2
SELECT * WHERE TO_CHAR from EMP (the hire_date, 'YYYYMMDD') = '20,080,411' (not used)
SELECT * WHERE EMP from the hire_date = TO_CHAR ( '20,080,411', 'YYYYMMDD') (use)
(2) when the query field is null index fail, causing full table scan.
where City is null or where City is not null,
Solution: Use the SQL syntax NULL will be a lot of trouble, the best index column is NOT NULL; for is null, you can build composite index.
nvl (field, 0), on the tables and indexes analyse, can be re-enabled when the index is null query finds, but the efficiency is not worthy of recognition; never use when the index is not null.
A large amount of data tables generally do not use the query is null.
select id from t where num is null
may be provided on a default value of 0 num, num column of the table to ensure that the value is not null, then this query:
SELECT ID WHERE num from T = 0
(3) used in the query is not equal operator (<>,! =) Limits index, causing a full table scan
Where city = 'TOKYO'!.
Solution: The operator is not equal to the change or, may be used index to avoid full table scan.
For example, the column <> 'aaa', into column < 'aaa' or column> 'aaa', you can use the index.
(4) The listed main index defined conditions, but the operating conditions employed, and like values with '%' is a start value or variable assignment. For example:
the WHERE City like '% YOK%'
the WHERE City like: City_bind_Variable xl_rao
the SELECT * from emp the WHERE name like '% A' (do not use an index)
the SELECT * from emp the WHERE name like 'A%' (to use an index)
solution: first, try to avoid fuzzy query, because if the business needs to be sure to use fuzzy queries, then at least do not use the full assurance fuzzy search, fuzzy search for the right,
that is like '...%', will use the index; left vague like '% .. 'can not directly use the index, but can use the reverse of the form + function index, change into like' ...% ';
the whole is not fuzzy optimization, it must then consider using the search engine. For reduce the load on the database server to consider, as much as possible to reduce the fuzzy database queries.
Improper use can cause 4.or statement full table scan
reason: the two conditions where clause comparison, an index, the index is not a use or would cause a full table scan.
For example: where A =: 1 or B =: 2, has an index A, B is not on the index, the comparison B =: restarts the full table scan 2
5. Fuzzy query is inefficient:
reason: like itself efficiency is relatively low, and should be avoided query using the like; for like '% ...%' this condition (full blur), can not use the index, a full table NATURAL inefficient scanning;
Further, since the relationship between the matching algorithms, fuzzy inquiry field length greater, the lower the fuzzy search efficiency.
Solution:
First, try to avoid fuzzy query, because if the business needs to be sure to use fuzzy queries, then at least do not use the full assurance fuzzy queries.
For the right fuzzy query, that is like '...%', will use the index;
left vague like '% ...' index can not be used directly, but you can use reverse form + function index, the change into like '...%';
full blur is not optimized, then we must consider the use of search engines. For reduce the load on the database server to consider, as much as possible to reduce the fuzzy database queries.
6. The select statement contains a query execution is slow null
reason: Oracle, a single query field is null when the index fail, causing full table scan.
Solution: Use the SQL syntax NULL will be a lot of trouble, the best index of the column is NOT NULL;
for is null, you can build composite index, on the tables and indexes analyse, is null query nvl (field 0) can re-enable the index to find, but the efficiency is not worthy of recognition;
never use when the index is not null. A large amount of data tables generally do not use the query is null.
7. The use of a query operator not equal (! <>, =) Performs the select statement slow
Cause: SQL, the operator is not equal to the index limits, causing full table scan, even on the index field comparison
solution : the operator is not equal to the change or, the index may be used to avoid full table scan.
For example, the column <> 'aaa', into column < 'aaa'or column>' aaa ', you can use the index.
8. The combination index, if the query is not the leading column, then the index does not work, will cause a full table scan;
but from Oracle9i, the introduction of an index skip scan characteristics, allows the optimizer may use a combination of an index, the index even the leading column does not appear in the WHERE clause.
For example:
Create index SKIP1 ON emp5 (Job, EMPNO);
full-index scan select count (*) from emp5 where empno = 7900;
index skip scan select / * + index (emp5 skip1 ) * / count (*) from emp5 where empno = 7900;
the former is a full table scan, the combination index is used.
9. or statement incorrectly can cause full table scan
reason: the two conditions where clause comparison, an index, the index is not a use or would cause a full table scan.
For example: where A =: 1 or B =: 2, there is an index on the A, B is not on the index, the comparison B =: restarts the full table scan 2.
10. The combination index, should be sorted from the sort index combination of the columns, even if only one of the index column is to be sorted, or sorted performance will be relatively poor.
For example:
Create index SKIP1 ON emp5 (Job, EMPNO, DATE);
SELECT Job, EMPNO from emp5 WHERE job = 'Manager' and EMPNO = '10 'Order by Job, EMPNO, DATE desc;
in fact only meet the query job = 'manager' and empno = '10 'recording date and press conditions in descending order, but the written order by date desc poor performance.
11.Update statement, if only to change the 2 fields, do not Update all fields, otherwise called frequently cause significant performance overhead, and bring a lot of logs.
12. For multi-table data amount Da JOIN, then first tab JOIN, or read and the logic high, poor performance.
COUNT 13.select (*) from the Table;
COUNT so without any conditions will cause full table scan, and no business sense, it is sure to put an end to.
where conditions 14.sql to bind variables, such as where column = 1, instead of writing where column = 'aaa', this will cause each execution will be re-analyzed, wasting CPU and memory resources.
15. Do not use in operator, so that the database will be a full table scan,
Recommended programs: intensive business which try not to use SQL IN operator
16.not in not in use and will not take the index
recommendations: use or not exists (external link + judge is empty) instead
17> and <operators (greater than or less than the operator)
is greater than or less than the operator under normal circumstances is not adjusted, the index will be used because it has an index lookup.
However, in some cases it may be optimized, such as a table has one million records, a numeric field A, 30 A = 0,30 recorded Wan Wan Wan recorded record A = 1,39 A = 2,1 Wan record of 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.
18.UNION operator
after performing UNION link table will filter out duplicate records, the result set in the table will link the generated sort operation, remove duplicate records and then returns the result.
Most practical applications are no duplicate records, the most common is the process table and the history table UNION. Such as:
the SELECT * from gc_dfys
of Union
the 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, and returns the result set, if the table is large amount of data, then use may cause disk sort.
Recommended Program: The alternative operator UNION ALL UNION, UNION ALL operation as simply merge the two results after return.
19.WHERE conditions affect the order behind
the WHERE clause of the order of a direct impact on large scale data query, such as
Select * from zl_yhjbqk where dy_dj = ' 1K hereinafter' = xh_bz. 1 and
the Select * from zl_yhjbqk WHERE xh_bz = 1 and dy_dj = '1K hereinafter'
two or more of the SQL dy_dj xh_bz no two fields and an index, so that when the full table scan is performed,
the first SQL the dy_dj = '1KV the following' conditions are set in the recording the ratio was 99%, while the ratio is only xh_bz = 0.5% during the first 99% of the time SQL records are compared and xh_bz of dy_dj.
When carrying out the second SQL 0.5% records are compared and xh_bz dy_dj, in order can be obtained second SQL CPU utilization was significantly lower than the first.
20. The impact of the order of the look-up table
in the list of the order in the table behind FROM 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 case,
thus because order of the table will not have a very consume server resources data cross. (Note: If the table is a statistical analysis, ORACLE links automatically advanced small table, and then link a large table)