Oracle query performance optimization

Principle 1: Pay attention to the connection order in the WHERE clause:
ORACLE parses the WHERE clause in a bottom-up order. According to this principle, the connection between tables must be written before other WHERE conditions, those that can filter out the maximum number of records Conditions must be written at the end of the WHERE clause.
Especially "primary key ID=?" such conditions.

Principle 2: Avoid using '*' in the SELECT clause:
During the parsing process, ORACLE will convert '*' into all column names in turn. This work is done by querying the data dictionary, which means that it will cost more time.

Simply put, the shorter the statement execution time, the better (especially for the end users of the system). For the query statement, because the full table scan reads a lot of data, especially for large tables, not only the query speed is slow, but also the pressure on disk IO is large, so it is usually avoided, and the way to avoid it is to use the index index.

The advantages and costs of using indexes.
Advantages:
1) The index is a conceptual part of the table, which is used to improve the efficiency of retrieving data. ORACLE uses a complex self-balancing B-tree structure. Generally, querying data through an index is faster than a full table scan. When ORACLE finds out The ORACLE optimizer will use indexes when executing the best path for queries and Update statements. Also, using indexes can improve efficiency when joining multiple tables.
2) Another benefit of using indexes is that they provide a primary key Uniqueness verification.. For those LONG or LONG RAW data types, you can index almost any column. In general, using an index is especially effective on large tables. Of course, you will also find that using an index can also improve efficiency when scanning small tables.
Cost: Although using an index can improve query efficiency, we must also pay attention to its cost. An index requires space for storage and regular maintenance. Whenever a record is added or deleted in the table or an index column is modified, the index itself will be modified. This means that INSERT , DELETE , UPDATE of each record will pay 4 or 5 more disk I/Os for this. Because indexes require additional storage space and processing, those unnecessary indexes will instead Makes query response time slower.. And the bigger the table, the more serious the impact.

Points to pay attention to when using indexes:

1. Avoid using NOT on indexed columns.　
We need to avoid using NOT on indexed columns. NOT will have the same effect as using functions on indexed columns. When ORACLE” encounters “NOT, He will stop using the index and perform a full table scan instead.

2. Avoid using calculations on indexed columns.
In the WHERE clause, if the indexed column is part of the function. The optimizer will use full table scans instead of indexes. Example:

Inefficient: SELECT … FROM DEPT WHERE SAL * 12 > 25000;
Efficient: SELECT … FROM DEPT WHERE SAL > 25000/12;
3. Avoid using IS NULL and IS NOT NULL on indexed columns
Avoid using any nullable column in the index, ORACLE performance will not be able to use the index. For single-column indexes, if the column contains nulls, the record will not exist in the index. For compound indexes, if every column is null, the record will also not exist in the index. If at least one column is not null, the record will exist in the index. Example: If the unique index is established on the A and B columns of the table, and there is a record in the table with the A, B value (123, null), ORACLE will not accept the next record with the same A, B value (123, null) records (inserts). However, if all index columns are null, ORACLE will consider the entire key value to be null and null is not equal to null. So you can insert 1000 records with the same key value, of course they are all null ! Because nulls do not exist in the indexed column, a null comparison of an indexed column in the WHERE clause will cause ORACLE to deactivate the index.


Inefficient: (index invalidation) SELECT ... FROM DEPARTMENT WHERE DEPT_CODE IS NOT NULL;
efficient: (The index is valid) SELECT … FROM DEPARTMENT WHERE DEPT_CODE >=0;
4. Pay attention to the influence
of Oracle may disable the index when wildcard is used. Such as:


SELECT...FROM DEPARTMENT WHERE DEPT_CODE like '%123456%' (invalid).
SELECT...FROM DEPARTMENT WHERE DEPT_CODE = '123456' (valid)

5. Avoid changing the type of the index column.:
When comparing data of different data types, ORACLE automatically performs simple type conversion on the column.
Suppose EMPNO is a numeric indexed column. SELECT … FROM EMP WHERE EMPNO = '123' In fact, after ORACLE type conversion, the statement is transformed into: SELECT … FROM EMP WHERE EMPNO = TO_NUMBER('123') Fortunately, the type The conversion does not occur on the indexed column, and the purpose of the index is not changed. Now, suppose EMP_TYPE is a character type indexed column. SELECT ... FROM EMP WHERE EMP_TYPE = 123 This statement is translated by ORACLE to: SELECT ... FROM EMP WHERETO_NUMBER(EMP_TYPE) =123 This index will not be used because of the type conversion that occurs internally! To avoid ORACLE from implicitly performing type conversions on your SQL, it is better to make the type conversion explicit. Be careful when comparing characters to numbers , ORACLE will preferentially convert numeric types to character types

6, some "temper" of the
index
Indexes may be slower than full table scans, but this is an order of magnitude difference. In general, using indexes is several times or even thousands of times more blocks than full table scans!

In addition to using indexes, we have other resources to reduce Consumption method:

1. Replace DISTINCT with EXISTS:
When submitting a query containing one-to-many table information (such as department table and employee table), avoid using DISTINCT in the SELECT clause. Generally, you can consider replacing it with EXIST, EXISTS makes The query is faster because the RDBMS core module will return the result as soon as the conditions of the subquery are met.
Example:

Copy Code
(inefficient): SELECT DISTINCT DEPT_NO,DEPT_NAME FROM DEPT D , EMP E
WHERE D.DEPT_NO = E.DEPT_NO
And E.sex =man
(efficient): SELECT DEPT_NO,DEPT_NAME FROM DEPT D
WHERE EXISTS
( SELECT 'X' FROM EMP E WHERE E.DEPT_NO = D.DEPT_NO And E.sex
=man
); Replacing OR with (UNION) UNION ALL (for indexed columns) Normally, replacing OR in a WHERE clause with UNION will Use OR on index columns will cause a full table scan. Note that the above rules are only valid for multiple index columns. If there are columns that are not indexed, the query efficiency may be reduced because you do not select OR. In the following example, both LOC_ID and REGION have indexes. If you insist on using OR, you need to write the index column with the fewest records at the top. Efficient: SELECT LOC_ID , LOC_DESC , REGION FROM LOCATION WHERE LOC_ID = 10 UNION ALL SELECT LOC_ID , LOC_DESC , REGION FROM LOCATION WHERE REGION = “MELBOURNE”










Inefficient: SELECT LOC_ID , LOC_DESC , REGION FROM LOCATION WHERE LOC_ID = 10 OR REGION = "MELBOURNE"
3. Replace UNION with UNION-ALL (if possible):
When the SQL statement needs to UNION two query result sets, these two The result sets will be merged in a UNION-ALL manner, and then sorted before outputting the final result. If UNION ALL is used instead of UNION, then sorting is not necessary. Efficiency will be improved as a result. Note that UNION ALL The same records in the two result sets will be output repeatedly. Therefore, you still need to analyze the feasibility of using UNION ALL from the business requirements. UNION will sort the result sets, and this operation will use the SORT_AREA_SIZE memory. The optimization of this memory is also Very important.
4. The Order By statement is added to the index column, preferably on the primary key PK.

SELECT DEPT_CODE FROM DEPT ORDER BY DEPT_TYPE (inefficient)
SELECT DEPT_CODE FROM DEPT ORDER BY DEPT_CODE (efficient)
5. Avoid resource-consuming operations:
SQL statements with DISTINCT, UNION, MINUS, and INTERSECT will start the SQL engine to execute resource-consuming operations. Sorting (SORT) function. DISTINCT requires one sorting operation, while others need to perform at least two sorting operations. Generally, SQL statements with UNION, MINUS, INTERSECT can be rewritten in other ways. If your database SORT_AREA_SIZE is adjusted Well, using UNION, MINUS, INTERSECT can also be considered, after all, they are very readable

6. Use Where instead of Having (if possible) to
optimize GROUP BY:
Improve the efficiency of GROUP BY statements by filtering out unwanted records before GROUP BY. The following two queries return the same results but the second one is significantly faster A lot.


Copy code
Inefficient :
SELECT JOB , AVG(SAL)
FROM EMP GROUP BY JOB HAVING JOB = 'PRESIDENT'AND AVG(SAL)>XXX
Efficient:
SELECT JOB , AVG(SAL)
FROM EMP
WHERE JOB = 'PRESIDENT'
OR JOB = 'MANAGER' GROUP BY JOB Having AVG(SAL)>XXX
Copy code
7. Generally speaking, if the statement can avoid the use of subqueries, try not to use subqueries. Because the overhead of subqueries is quite expensive. The specific example is in the following case "Optimization of a SQL".