Original http://database.51cto.com/art/200904/118526.htm
1. Fuzzy matching of queries
Try to avoid using LIKE '%parm1%' in a complex query - the percent sign in red will make the index of the relevant column unavailable, so it is best not to use it.
Solution:
In fact, only a slight improvement to the script is required, and the query speed will be increased by nearly a hundred times. The improvement method is as follows:
a. Modify the front-end program - change the supplier name column of the query condition from the original text input to a drop-down list. When the user vaguely enters the supplier's name, it will directly help locate the specific supplier in the front-end, so that when calling the background program, this column can be directly associated with equals.
b. Modify the background directly - according to the input conditions, first find out the qualified suppliers, and save the relevant records in a temporary table, and then use the temporary table to make complex associations
2. Indexing issues
In the process of performance tracking analysis, it is often found that the performance problems of many background programs are caused by the lack of suitable indexes, and some tables do not even have an index. This situation is often because the index was not defined when the table was designed. In the early stage of development, since there are few table records, whether the index is created or not may have little effect on the performance, so the developers did not pay much attention to it. However, once the program is released to the production environment, over time, the table records more and more
At this time, the lack of indexes will have an increasing impact on performance.
This problem requires the joint attention of database designers and developers
Rule: Do not perform the following operations on the data columns of the established index:
◆Avoid calculation operations on index fields
◆ Avoid using not, <>, != on index fields
◆Avoid using IS NULL and IS NOT NULL on indexed columns
◆Avoid data type conversion on indexed columns
◆Avoid using functions on index fields
◆ Avoid using null values in indexed columns.
3. Complex operation
Some UPDATE and SELECT statements are very complicated to write (multi-level subqueries are often nested) - you can consider splitting them into several steps, first generate some temporary data tables, and then perform association operations
4.update
The modification of the same table occurs dozens of times in a process, such as:
update table1 |
Scripts like this can actually be easily integrated into an UPDATE statement (some time ago, I found this situation when assisting the xxx project to analyze performance problems)
5. In the statement that can use UNION ALL, UNION is used
Because UNION compares the records of each query subset, it is usually much slower than UNION ALL. In general, if using UNION ALL can meet the requirements, be sure to use UNION ALL. There is another situation that you may ignore, that is, although the union of several subsets is required to filter out duplicate records, due to the particularity of the script, it is impossible to have duplicate records. In this case, UNION ALL should be used, such as the xx module. A query program used to have this situation. See, due to the particularity of the statement, the records of several subsets in this script are absolutely impossible to repeat, so UNION ALL can be used instead)
6. In the WHERE statement, try to avoid calculating the index field
I believe that most developers should know this common sense, but there are still many people who use it like this. I think one of the main reasons may be that the performance is damaged for the sake of simplicity, which is not desirable.
During the performance analysis of the XX system in September, it was found that there are a large number of background programs with similar usage, such as:
...... |
Although the create_date field has been indexed, the index cannot be used due to the addition of TRUNC. The correct spelling here should be
where create_date>=trunc(:date1) and create_date<trunc(:date1)+1< pre=""> |
or
where create_date between trunc(:date1) and trunc(:date1)+1-1/(24*60*60) |
Note: Because the range between is a closed interval (greater than or equal to low value and less than or equal to high value.),
Therefore, in a strict sense, a decimal that tends to 0 should be subtracted. Here, it is temporarily set to subtract 1 second (1/(24*60*60)). If you do not require such precision, you can skip this step.
7. Rules for Where Statements
7.1 Avoid using in, not in, or or having in the WHERE clause .
Instead of in and not in, exist and not exist can be used.
A table link can be used instead of exist. Having can be replaced by where, and if it cannot be replaced, it can be processed in two steps.
example
SELECT * FROM ORDERS WHERE CUSTOMER_NAME NOT IN |
optimization
|
7.2 Do not declare numbers in character format, declare character values in numeric format . (Same for date) Otherwise, the index will be invalidated, resulting in a full table scan.
Example use:
SELECT emp.ename, emp.job FROM emp WHERE emp.empno = 7369; |
8. Rules for Select Statements
在应用程序、包和过程中限制使用select * from table这种方式。看下面例子
使用SELECT empno,ename,category FROM emp WHERE empno = '7369‘ |
9. 排序
避免使用耗费资源的操作，带有DISTINCT,UNION,MINUS,INTERSECT,ORDER BY的SQL语句会启动SQL引擎 执行，耗费资源的排序(SORT)功能. DISTINCT需要一次排序操作, 而其他的至少需要执行两次排序
10.临时表
慎重使用临时表可以极大的提高系统性能