Oracle database performance optimization-summary of execution plan exception cases

1. Hash connection can only be used in equal connection conditions

2. The choice of drive table has an impact on operating efficiency and performance

3. The driven table and driven table can be accessed at most once

4 Modifying the parameter OPTIMIZE_mode at the session level to first rows 10 causes the cbo to incorrectly evaluate the COST value of the full table scan of the large table, resulting in an abnormal execution plan.

5 Binding variables peeking, resulting in abnormal execution plan (inherit the first execution plan)

6 The 11.2 version uses a new feature feedback which causes the execution plan to be abnormal.

 

 

30000,,30000,190000; --HASH connection, no good index,

 

 

Case 1 The access filter uses the wrong predicate.

select count(1) FROM T1 WHERE ID1>20 AND ID1>10

The execution plan is to use id1>10 ACCESS and ID2>20 FILTER, which is obviously problematic.

 

Case 2 Bitmap conversion using improper index

select *from t1 where iddate>=sysdate-1 and idname ='123';

The execution plan uses the IDDATE column and the idname column bitmap conversion. The correct execution plan should be ACCESS for ID1DATE and FILTER for IDNAME='123'.

Case 3 The statistical information is incorrect and the wrong index is used 

Guess you like

Origin blog.csdn.net/oradbm/article/details/113119166