Ten lessons from SQL performance optimization

1. Fuzzy matching of queries

Try to avoid using LIKE '%parm1%' in a complex query - the percent sign in the red mark position will make the index of the relevant column unusable, so it is best not to use it.

Solution:

In fact, you only need to The script is slightly improved, and the query speed will be increased by nearly a hundred times. The improvement methods are as follows:

a. Modify the foreground 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 name, it will help locate the specific supplier directly in the foreground. In this way, 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. Index problems

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, and 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 affect the performance more and more.

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 calculating operations on index fields

◆Avoid using not, <>, != on index fields

◆Avoid Use IS NULL and IS NOT NULL

on indexed columns ◆ Avoid data type conversion on indexed columns

◆ Avoid using functions on indexed fields

◆ Avoid using null values ​​in indexed columns.



3. Complex operations

Some UPDATE and SELECT statements are very complex (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 same table Modification occurs dozens of times in a process, such as:

update table1

set col1=...

where col2=...;

update table1

set col1=...

where col2=...

 ...



like this In fact, the class script can be easily integrated into an UPDATE statement (some time ago, I found this situation when assisting the xxx project to analyze the performance problem)



5. In the statement that can use UNION ALL, UNION

UNION is used because The records of each query subset will be compared, so the speed is usually much slower than UNIONALL. 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 certain query program used to have this situation. See, due to the particularity of the statement, it is absolutely impossible for the records of several subsets to be repeated in this script, so UNION ALL can be used instead.)



6. In the WHERE statement, try to avoid I believe most developers should know

this common sense to perform calculation operations on index fields , but there are still many people who use it like this. I think one of the main reasons may be that it is simple to write and damage performance, which is not desirable.

In September, when I analyzed the performance of the XX system, I found that there are a large number of background programs with similar usage, such as:

......

where trunc(create_date)=trunc(:date1)



Although the create_date field has been indexed, but Because of the addition of TRUNC, the index cannot be used. The correct spelling here should be

where create_date>=trunc(:date1) andcreate_date[tr]</trunc(:date1)+1

or

where create_date between trunc(:date1) andtrunc(: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.), in

a strict sense, a decimal that tends to 0 should be subtracted. Set to subtract 1 second (1/(24*60*60)), if you don't 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

(SELECT CUSTOMER_NAME FROM CUSTOMER)



Optimize



SELECT * FROM ORDERS WHERE CUSTOMER_NAME not exist

(SELECT CUSTOMER_NAME FROM CUSTOMER)



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 WHEREemp.empno = 7369;

do not use: SELECT emp.ename, emp.job FROM emp WHERE emp.empno = '7369'



8. Rules for Select Statements

in Application , packages and procedures are restricted to use select * from table in this way. See the example below

Use SELECT empno,ename,category FROM emp WHERE empno = '7369'

instead of SELECT * FROM emp WHERE empno = '7369'



9. Sorting

Avoid expensive operations with DISTINCT,UNION,MINUS,INTERSECT , The SQL statement of ORDER BY will start the SQL engine to execute the resource-consuming sorting (SORT) function. DISTINCT requires one sorting operation, while others need at least two sorting operations.



10. Temporary tables

Careful use of temporary tables can greatly improve the system Oh performance.

The above are the ten experiences about SQL performance optimization

shared .