1 Nested loop connection
Condition 1: If the number of records in the driving result set corresponding to the driving table is small, and there is a unique index in the connection column of the driven table (or there is a very selective non-unique index in the connection column of the driven table )
Then use nested loop connection. If the number of records corresponding to the drive result set corresponding to the drive table is large, the efficiency will not be high even if there is an index in the connection column.
Condition 2 : The driving result set is a large table. After filtering by the predicate condition, the driving result set can be reduced.
Advantages: Compared with other connections, the nested loop connection can achieve quick response, that is, it returns the number of record rows that have met the conditions in the first time.
Summary: Smaller driving result set, the connected column of the driven table has a more selective index
Case 1
select *from a ,b where a.date=sysdate-10 and a.id=b.id (where a table is selected by the predicate handsome, there are 10W, the data volume of b table is 3000, then the execution plan is driven by table A, b The table is driven, take nl connection, the connection column has a unique index bus)
2 Hash connection
1 The number of driven result sets is large, the connection column does not have a suitable index, and the corresponding HASH table of the driven result set can be completely contained in the PGA through the hash luck calculation.
2 The selectivity of the connection column is very good. If it is not good, it may result in a large number of records in the hash table, resulting in high CPU consumption and low logical reading. (Read the PGA hash table).
3 Anti-connection
For the use of the not in not exists <>ALL condition, the subquery is used to expand the connection.
SQL> create table ac1 as select * from dba_objects;
The table has been created.
SQL> create table ac2 as select * from ac1
2 ;
The table has been created.
SQL> select * from ac1 where ac1.object_id not in (select object_id from ac2);
No rows selected
SQL> set autotrace traceonly;
SQL> select * from ac1 where ac1.object_id not in (select object_id from ac2);
No rows selected
Execution plan
------------------------------------------------ ----------
Plan hash value: 2231603900----------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
----------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 72330 | 34M| | 2547 (1)| 00
:00:01 |
|* 1 | HASH JOIN RIGHT ANTI NA| | 72330 | 34M| 1712K| 2547 (1)| 00
:00:01 |
| 2 | TABLE ACCESS FULL | AC2 | 69805 | 886K| | 387 (1)| 00
:00:01 |
| 3 | TABLE ACCESS FULL | AC1 | 72330 | 33M| | 389 (1)| 00
:00:01 |
Predicate Information (identified by operation id):
---------------------------------------------------1 - access("AC1"."OBJECT_ID"="OBJECT_ID")
- dynamic statistics used: dynamic sampling (level=2)统计信息
----------------------------------------------------------
0 recursive calls
5 db block gets
1435 consistent gets
0 physical reads
0 redo size
2168 bytes sent via SQL*Net to client
597 bytes received via SQL*Net from client
1 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
0 rows processedSQL>
Semi-connected s
HASH JOIN SEMI
select * from t1 where t1.id in(select t2.id from t2);
select *from t1 where exists(select 1 from t2 where t1.id=t2.id);
Study Case:
One sql corresponds to three execution plans. That is 3 plan_HASH_VALUE.
Select the execution plan of value1 during the problem. (A full table scan is performed on a table with 740W data), the corresponding cost values of the corresponding sql are basically close.
case study:
1 View statistics.
2 View real table data information
Reason analysis and summary: 1 According to the execution plan statistics, it is found that the cost value of a full table scan of a 740w table is only 10, (it should be in a few hundred k), and the statistical information num rows is more than 600 w, which is more accurate.
2 Through analysis, it is found that the cost value estimated for the full table scan is inaccurate due to the modification of the optimizer MODE parameter of the session level to first_rows_10. As a result, the CBO chooses the wrong cost value to execute the plan when choosing to execute the call.
3 The reason that the CBO estimates that the full table scan operation cost of a large table with an actual data volume of 730W and accurate statistics is only 2 is that the parameter optimizer_mode is modified to first_rows_10, which leads to the problem of slower system login interval.
SQL> show parameter mode
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
instance_mode string READ-WRITE
optimizer_mode string ALL_ROWS
remote_dependencies_mode string TIMESTAMP
result_cache_mode string MANUAL
SQL>
Summary of knowledge points:
1 The query efficiency through the b-tree index will not decrease due to the increase in the amount of table data.
2 Where the keyword (+) appears, it indicates that the corresponding object should be completed with null.
3 Oracle index skip scan, the smaller the leading column distinct value, the better.
4 Large tables can also be used as driving tables, but access or filter of predicate conditions is required to reduce the amount of data.