1. General description
The distinctive feature of the database system is that it needs to save a large number of historical records. There are many historical record tables in the system. Therefore, it often occurs that the system runs for a period of time, and the system response becomes significantly slower after the number of table records reaches a certain number. In order to avoid this situation, under a complete database object design, the data changes under the system stability are also taken into consideration. In response to such changes, certain optimization rules must be followed when writing SQL statements, and a complete set of optimization rules must be formulated. Data management mechanism.
2. Tuning purpose
Using Oracle's internal optimizer working mechanism, rationally improve the organization of query statements, improve the response speed of the database system, and realize the rapid response capability of front-end screen and platform applications;
3. Tuning principles
Make full use of table indexes to avoid full table scans; make full use of the SGA shared pool cache mechanism to advance Oracle's work efficiency, make full use of structured programming methods, and improve query reuse capabilities.
4. Tuning method
4.1 Writing method
4.1.1 SQL statement with the same function and performance
ORACLE adopts the mechanism of shared memory SGA, so ORACLE will analyze each SQL written in different ways and occupy shared memory; if the writing format is exactly the same, ORACLE will only analyze it once, and encountering SQL in the same writing format, it will directly share the Obtain result sets in memory; this reduces shared pool overhead and code reuse.
Processing method: Ensure that the writing format is the same, including the same case, space position, table alias, etc.; use some common SQL statements as public functions to be called by other functions.
4.1.2 Dynamic SQL
Dynamic SQL adopts the way of dynamic variable binding to avoid repeated parsing.
4.2 Connection method and sequence
4.2.1 Table name sequence
When querying multiple tables, you need to choose the most efficient table name order (the rule-based optimizer is effective), and ORACLE's parser processes the table names in the FROM clause from right to left; therefore, it is written in the last foundation. The table is processed first, that is, the table with the least number of records is selected as the base table. First, the rightmost table in the FROM clause is scanned, and the records are sorted, then the last second table in the FROM clause is scanned, and finally Merge all records retrieved from the second table with the appropriate records in the first table.
4.2.2 Query condition sequence
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 conditions that can filter out the maximum number of records are suitable for writing at the end of the WHERE clause.
4.3 Syntax and Semantics
4.3.1 Avoid ' * ' in SELECT clause
Using '*', Oracle will query the data dictionary and parse each column name in turn. The name of each column should be clearly specified, which is also easy to understand.
4.3.2 Using table aliases (Alias)
When querying multiple tables, using table aliases can also avoid parsing, ambiguity, and advance efficiency.
4.4 Functions and Expressions
4.4.1 Replacing > with >=
If there is an index on DEPTNO,
efficient:
SELECT *
FROM EMP
WHERE DEPTNO >= 4
Inefficient:
SELECT *
FROM EMP
WHERE DEPTNO > 3
The difference between the two is that the former DBMS will directly jump to the first record with DEPT equal to 4 and then The operator will first locate the record with DEPTNO=3 and scan forward to the first record with DEPT greater than 3.
4.4.2 Use the DECODE function to reduce processing time
Use the DECODE function to avoid repeatedly scanning the same records or repeatedly joining the same table.
4.4.3 Replacing DELETE with TRUNCATE
When deleting records in a table, under normal circumstances, rollback segments are used to store information that can be recovered. If you do not have a COMMIT transaction, ORACLE will restore the data to the state before the deletion (to be precise, restore to the state before the delete command was executed)
and when TRUNCATE is used, the rollback segment no longer stores any information that can be restored. When the command is run, the data cannot be restored. Therefore, few resources are called, and the execution time will also Very short.
TRUNCATE is only applicable to delete full table or partition, TRUNCATE is DDL not DML
4.5 Common keyword priority
4.5.1 Use EXISTS instead of IN
Using IN will enable a full table scan, and using EXISTS will make use of indexes to improve query efficiency.
4.5.2 Replacing NOT IN with NOT EXISTS
Using NOT IN will enable full table scan, using NOT EXISTS will utilize indexes and improve query efficiency.
4.5.3 Replacing EXISTS with table joins
4.5.4 Replacing DISTINCT with EXISTS
4.5.5 Avoiding IS NULL and IS NOT NULL on indexed columns
If the index contains any nullable column, ORACLE will not be able to use the index, for example:
Inefficient: (index invalid)
SELECT …
FROM DEPARTMENT
WHERE DEPT_CODE IS NOT NULL;
efficient: (index valid)
SELECT …
FROM DEPARTMENT
WHERE DEPT_CODE >=0;
4.5.6 Replacing UNION with UNION-ALL
When the SQL statement needs to UNION two query result sets, the two result sets will be combined 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 thus be improved.
4.5.7 Replacing OR with UNION (for indexed columns)
In general, replacing OR in the WHERE clause with UNION will work better. Using OR on indexed columns will result in a full table scan. Note that the above rules are only valid for multiple indexed columns. Index, query efficiency may be reduced because you do not choose OR.
4.5.8 Replacing ORDER BY with WHERE
The ORDER BY clause uses an index only under two strict conditions.
All columns in ORDER BY must be included in the same index and maintain the order in which they are listed.
All columns in ORDER BY must be defined as non-null.
WHERE The index used in the clause and the index used in the ORDER BY clause cannot be concurrent.
4.5.9 Replacing the HAVING clause with a WHERE clause
Avoid using the HAVING clause, HAVING will only filter the result set after all records have been retrieved. This processing requires sorting, totaling, etc. If you can limit the number of records by the WHERE clause, you can reduce this overhead. .Example
:
Inefficient:
SELECT REGION, AVG(LOG_SIZE)
FROM LOCATION
GROUP BY REGION
HAVING REGION REGION != 'SYDNEY'
AND REGION != 'PERTH'
Efficient
SELECT REGION, AVG(LOG_SIZE)
FROM LOCATION
WHERE REGION REGION != 'SYDNEY The conditions in '
AND REGION != 'PERTH'
GROUP BY REGION
HAVING are generally used for comparison of some aggregate functions, such as COUNT() etc. In addition, the general conditions should be written in the WHERE clause.
4.5.10 Use of GROUP BY
The efficiency of the GROUP BY statement can be improved by filtering out unwanted records before the GROUP BY. The following two queries return the same results but the second one is significantly faster.
4.6 Global parameters
4.7 Other factors
4.7.1 Reduce the number of database visits
When executing each SQL statement, ORACLE does a lot of work internally:
? Parse SQL statements
? Estimate index utilization
? bind variables
? read data blocks, etc.
It can be seen that reducing the number of times the database is accessed can actually reduce the workload of ORACLE.
4.7.2 COMMIT is often used
Whenever possible, use COMMIT as much as possible in the program, so that the performance of the program is improved, and the demand will be reduced because of the resources released by COMMIT. Resources released by COMMIT:
ü Information on the rollback segment used to restore data.
ü The lock acquired by the program statement
ü space in redo log buffer
ü ORACLE manages the internal costs of the above 3 resources
4.8 Introduction to Common Optimization Tools
4.8.1 Analyze SQL Statements with Explain Plan
EXPLAIN PLAN is a good tool for analyzing SQL statements. It can even analyze statements without executing SQL. Through analysis, we can know how ORACLE connects tables and scans tables (index scan or full scan) table scan) and the index name used.
4.8.2 TRACE of SQL PLUS
5. Common terms
5.1 Full table scan
A full table scan is to access each record in the table sequentially. ORACLE optimizes the full table scan by reading multiple data blocks at a time.
5.2 Access by index (ROWID)
ROWID contains the physical location information of the records in the table. ORACLE uses the index to realize the connection between the data and the physical location (ROWID) where the data is stored. Usually, the index provides a method to quickly access the ROWID, so those queries based on index columns can Get performance improvements.
5.3 Shared SQL
? Oracle provides a mechanism for caching executed SQL statements. The SQL statements that have been parsed and the execution path determined are stored in the shared pool of the SGA.
? Before executing an SQL statement, Oracle checks whether there is a buffered SQL statement in the SGA shared pool each time, and executes the SQL statement directly if there is one.
? The purpose of improving Oracle execution performance can be achieved by appropriately adjusting the size of the SGA shared pool.
5.4 ORACLE Optimizer
? RULE (rule-based)
? COST (cost based)
? CHOOSE (optional)