1. The efficiency of fuzzy query is very low:
Reason: the efficiency of like itself is relatively low, and the use of like in query conditions should be avoided as much as possible ; for conditions such as like '%...%' (full fuzzy), the index cannot be used. The scanning efficiency is naturally low; in addition, due to the relationship of the matching algorithm, the larger the field length of the fuzzy query, the lower the efficiency of the fuzzy query.
Solution: First try to avoid fuzzy query. If you must use fuzzy query , at least make sure not to use full fuzzy query. For right fuzzy query, that is, like '...%', index will be used; left fuzzy like
'%...' cannot use the index directly, but it can be changed to like '...%' by using the form of reverse + function index; full ambiguity cannot be optimized, so consider using a search engine if necessary. In order to reduce the load of the database server, reduce the database fuzzy query as much as possible.
2. The slow execution of the select statement with is null in the query condition
: In Oracle 9i, when the query field is null, the single index fails, causing a full table scan.
Solution: Using NULL in SQL syntax will cause a lot of trouble, it is best to use NOT NULL for the index columns; for is null, you can create a composite index, nvl(field, 0), after analyzing the table and index, is null when querying Index lookups can be re-enabled, but the efficiency is not yet positive; the index is never used when it is not null. Generally, tables with large amounts of data should not be queried with is null.
3. The select statement that uses the unequal operator (<>, !=) in the query condition is slow to execute.
Reason: In SQL, the unequal operator will limit the index and cause a full table scan, even if there is an index on the compared field
Solution: By changing the not equal operator to or, you can use an index to avoid a full table scan. For example, change column<>'aaa' to column<'aaa' or column>'aaa' to use the index.
4. Use a composite index. If there is no leading column in the query condition, the index will not work and will cause a full table scan; but since Oracle9i, the feature of index skip scan has been introduced, which allows the optimizer to use the composite index, even if the index The leading columns of 's do 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, and the latter will use a composite index.
5. Improper use of the or statement will cause a full table scan
Reason: two conditions compared in the where clause, one with an index and one without an index, using or will cause a full table scan. For example: where A=:1 or B=:2, there is an index on A and no index on B, then the full table scan will be restarted when B=:2 is compared.
6. Combined index, the sorting should be done according to the order of the columns in the combined index, even if there is only one column in the index to be sorted, otherwise the sorting performance will be 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 the query matches job= The records of the 'manager'and empno='10' condition are sorted in descending order by date, but the performance of writing order by date desc is poor.
7. Update statement, if only 1 or 2 fields are changed, do not update all fields, otherwise frequent calls will cause obvious performance consumption and bring a lot of logs.
8. For multiple JOIN tables with a large amount of data (hundreds are considered large here), you must first paginate and then JOIN, otherwise the logical read will be very high and the performance will be poor.
9. select count(*) from table; such a count without any conditions will cause a full table scan, and has no business meaning, it must be avoided.
10. The where condition of sql should be bound to a variable, such as where column=: 1, do not write where column='aaa', which will cause re-analysis every time it is executed, wasting CPU and memory resources.
Reason: the efficiency of like itself is relatively low, and the use of like in query conditions should be avoided as much as possible ; for conditions such as like '%...%' (full fuzzy), the index cannot be used. The scanning efficiency is naturally low; in addition, due to the relationship of the matching algorithm, the larger the field length of the fuzzy query, the lower the efficiency of the fuzzy query.
Solution: First try to avoid fuzzy query. If you must use fuzzy query , at least make sure not to use full fuzzy query. For right fuzzy query, that is, like '...%', index will be used; left fuzzy like
'%...' cannot use the index directly, but it can be changed to like '...%' by using the form of reverse + function index; full ambiguity cannot be optimized, so consider using a search engine if necessary. In order to reduce the load of the database server, reduce the database fuzzy query as much as possible.
2. The slow execution of the select statement with is null in the query condition
: In Oracle 9i, when the query field is null, the single index fails, causing a full table scan.
Solution: Using NULL in SQL syntax will cause a lot of trouble, it is best to use NOT NULL for the index columns; for is null, you can create a composite index, nvl(field, 0), after analyzing the table and index, is null when querying Index lookups can be re-enabled, but the efficiency is not yet positive; the index is never used when it is not null. Generally, tables with large amounts of data should not be queried with is null.
3. The select statement that uses the unequal operator (<>, !=) in the query condition is slow to execute.
Reason: In SQL, the unequal operator will limit the index and cause a full table scan, even if there is an index on the compared field
Solution: By changing the not equal operator to or, you can use an index to avoid a full table scan. For example, change column<>'aaa' to column<'aaa' or column>'aaa' to use the index.
4. Use a composite index. If there is no leading column in the query condition, the index will not work and will cause a full table scan; but since Oracle9i, the feature of index skip scan has been introduced, which allows the optimizer to use the composite index, even if the index The leading columns of 's do 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, and the latter will use a composite index.
5. Improper use of the or statement will cause a full table scan
Reason: two conditions compared in the where clause, one with an index and one without an index, using or will cause a full table scan. For example: where A=:1 or B=:2, there is an index on A and no index on B, then the full table scan will be restarted when B=:2 is compared.
6. Combined index, the sorting should be done according to the order of the columns in the combined index, even if there is only one column in the index to be sorted, otherwise the sorting performance will be 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 the query matches job= The records of the 'manager'and empno='10' condition are sorted in descending order by date, but the performance of writing order by date desc is poor.
7. Update statement, if only 1 or 2 fields are changed, do not update all fields, otherwise frequent calls will cause obvious performance consumption and bring a lot of logs.
8. For multiple JOIN tables with a large amount of data (hundreds are considered large here), you must first paginate and then JOIN, otherwise the logical read will be very high and the performance will be poor.
9. select count(*) from table; such a count without any conditions will cause a full table scan, and has no business meaning, it must be avoided.
10. The where condition of sql should be bound to a variable, such as where column=: 1, do not write where column='aaa', which will cause re-analysis every time it is executed, wasting CPU and memory resources.