Oracle中Hint深入理解(原創)
Hint
概述
基於代價的優化器是很聰明的,在絕大多數情況下它會選擇正確的優化器,減輕了DBA
的負擔。但有時它也聰明反被聰明誤,選擇了很差的執行計劃,使某個語句的執行變得奇慢無比。
此時就需要DBA
進行人為的干預,告訴優化器使用我們指定的存取路徑或連線型別生成執行計劃,從 而使語句高效的執行。例如,如果我們認為對於一個特定的語句,執行全表掃描要比執行索引掃描更有效,則我們就可以指示優化器使用全表掃描。在Oracle
中,是通過為語句新增 Hints
(提示)來實現干預優化器優化的目的。
不建議在程式碼中使用hint
,在程式碼使用hint使得CBO
無法根據實際的資料狀態選擇正確的執行計劃。畢竟 資料是不斷變化的, 10g以後的CBO
也越來越完善,大多數情況下我們該讓Oracle
自行決定採用什麼執行計劃。
Oracle Hints
是一種機制,用來告訴優化器按照我們的告訴它的方式生成執行計劃。我們可以用Oracle Hints
來實現:
- 使用的優化器的型別
- 基於代價的優化器的優化目標,是
all_rows
還是first_rows
。 - 表的訪問路徑,是全表掃描,還是索引掃描,還是直接利用
rowid
。 - 表之間的連線型別
- 表之間的連線順序
- 語句的並行程度
除了”RULE”提示外,一旦使用的別的提示,語句就會自動的改為使用CBO
優化器,此時如果你的資料字典中沒有統計資料,就會使用預設的統計資料。所以建議大家如果使用CBO
或Hints
提示,則最好對錶和索引進行定期的分析。
如何使用Hints
:
Hints
只應用在它們所在sql語句塊(statement block
,由select、update、delete
關鍵字標識)上,對其它SQL語句或語句的其它部分沒有影響。如:對於使用union操作的2個sql語句,如果只在一個sql語句上有Hints,則該Hints
不會影響另一個sql語句。
我們可以使用註釋(comment
)來為一個語句新增Hints
,一個語句塊只能有一個註釋,而且註釋只能放在SELECT, UPDATE, or DELETE
關鍵字的後面
使用Oracle Hints的語法:
{DELETE|INSERT|SELECT|UPDATE} /*+ hint [text] [hint[text]]... */
or
{DELETE|INSERT|SELECT|UPDATE} --+ hint [text] [hint[text]]...
註解:
DELETE、INSERT、SELECT
和UPDATE
是標識一個語句塊開始的關鍵字,包含提示的註釋只能出現在這些關鍵字的後面,否則提示無效。- “+”號表示該註釋是一個
Hints
,該加號必須立即跟在”/*”的後面,中間不能有空格。 hint
是下面介紹的具體提示之一,如果包含多個提示,則每個提示之間需要用一個或多個空格隔開。text
是其它說明hint的註釋性文字
5)使用表別名。如果在查詢中指定了表別名,那麼提示必須也使用表別名。例如:select /*+ index(e,dept_idx) */ * from emp e;
6)不要在提示中使用模式名稱:如果在提示中指定了模式的所有者,那麼提示將被忽略。例如:
select /*+ index(scott.emp,dept_idx) */ * from emp
注意:如果你沒有正確的指定Hints
,Oracle將忽略該Hints
,並且不會給出任何錯誤。
hint
被忽略
如果CBO
認為使用hint
會導致錯誤的結果時,hint
將被忽略,詳見下例
SQL> select /*+ index(t t_ind) */ count(*) from t;
Execution Plan
----------------------------------------------------------
Plan hash value: 2966233522
-------------------------------------------------------------------
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
-------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 57 (2)| 00:00:01 |
| 1 | SORT AGGREGATE | | 1 | | |
| 2 | TABLE ACCESS FULL| T | 50366 | 57 (2)| 00:00:01 |
-------------------------------------------------------------------
因為我們是對記錄求總數,且我們並沒有在建立索引時指定不能為空,索引如果CBO
選擇在索引上進行count
時,但索引欄位上的值為空時,結果將不準確,故CBO沒有選擇索引。
SQL> select /*+ index(t t_ind) */ count(id) from t;
Execution Plan
----------------------------------------------------------
Plan hash value: 646498162
--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 5 | 285 (1)| 00:00:04 |
| 1 | SORT AGGREGATE | | 1 | 5 | | |
| 2 | INDEX FULL SCAN| T_IND | 50366 | 245K| 285 (1)| 00:00:04 |
--------------------------------------------------------------------------
因為我們只對id
進行count
,這個動作相當於count
索引上的所有id
值,這個操作和對錶上的id
欄位進行count
是一樣的(組函式會忽略null
值)
Hint
的具體用法
和優化器相關的hint
1、/*+ ALL_ROWS */
表明對語句塊選擇基於開銷的優化方法,並獲得最佳吞吐量,使資源消耗最小化.
SELECT /*+ ALL+_ROWS*/ EMP_NO,EMP_NAM,DAT_IN FROM BSEMPMS WHERE EMP_NO='SCOTT';
2、/*+ FIRST_ROWS(n) */
表明對語句塊選擇基於開銷的優化方法,並獲得最佳響應時間,使資源消耗最小化.
SELECT /*+FIRST_ROWS(20) */ EMP_NO,EMP_NAM,DAT_IN FROM BSEMPMS WHERE EMP_NO='SCOTT';
3、/*+ RULE*/
表明對語句塊選擇基於規則的優化方法.
SELECT /*+ RULE */ EMP_NO,EMP_NAM,DAT_IN FROM BSEMPMS WHERE EMP_NO='SCOTT';
和訪問路徑相關的hint
1、/*+ FULL(TABLE)*/
表明對錶選擇全域性掃描的方法.
SELECT /*+FULL(A)*/ EMP_NO,EMP_NAM FROM BSEMPMS A WHERE EMP_NO='SCOTT';
2、/*+ INDEX(TABLE INDEX_NAME) */
表明對錶選擇索引的掃描方法.
SELECT /*+INDEX(BSEMPMS SEX_INDEX) */ * FROM BSEMPMS WHERE SEX='M';
5、/*+ INDEX_ASC(TABLE INDEX_NAME)*/
表明對錶選擇索引升序的掃描方法.
SELECT /*+INDEX_ASC(BSEMPMS PK_BSEMPMS) */ * FROM BSEMPMS WHERE DPT_NO='SCOTT';
6、/*+ INDEX_COMBINE*/
為指定表選擇點陣圖訪問路經,如果INDEX_COMBINE中沒有提供作為引數的索引,將選擇出點陣圖索引的布林組合方式.
SELECT /*+INDEX_COMBINE(BSEMPMS SAL_BMI HIREDATE_BMI) */ * FROM BSEMPMS
WHERE SAL<5000000 AND HIREDATE
7、/*+ INDEX_JOIN(TABLE INDEX_NAME1 INDEX_NAME2) */
當謂詞中引用的列都有索引的時候,可以通過指定採用索引關聯的方式,來訪問資料
select /*+ index_join(t t_ind t_bm) */ id from t where id=100 and object_name='EMPLOYEES'
8、/*+ INDEX_DESC(TABLE INDEX_NAME)*/
表明對錶選擇索引降序的掃描方法.
SELECT /*+INDEX_DESC(BSEMPMS PK_BSEMPMS) */ * FROM BSEMPMS WHERE DPT_NO='SCOTT';
9、/*+ INDEX_FFS(TABLE INDEX_NAME) */
對指定的表執行快速全索引掃描,而不是全表掃描的辦法.
SELECT /* + INDEX_FFS(BSEMPMS IN_EMPNAM)*/ * FROM BSEMPMS WHERE DPT_NO='TEC305';
10、/*+ INDEX_SS(T T_IND) */
從9i開始,oracle引入了這種索引訪問方式。當在一個聯合索引中,某些謂詞條件並不在聯合索引的第一列時,可以通過Index Skip Scan
來訪問索引獲得資料。當聯合索引第一列的唯一值個數很少時,使用這種方式比全表掃描效率高。
SQL> create table t as select 1 id,object_name from dba_objects;
Table created.
SQL> insert into t select 2,object_name from dba_objects;
50366 rows created.
SQL> insert into t select 3,object_name from dba_objects;
50366 rows created.
SQL> insert into t select 4,object_name from dba_objects;
50366 rows created.
SQL> commit;
Commit complete.
SQL> create index t_ind on t(id,object_name);
Index created.
SQL> exec dbms_stats.gather_table_stats('HR','T',cascade=>true);
PL/SQL procedure successfully completed.
執行全表掃描
SQL> select /*+ full(t) */ * from t where object_name='EMPLOYEES';
6 rows selected.
Execution Plan
----------------------------------------------------------
Plan hash value: 1601196873
--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 5 | 135 | 215 (3)| 00:00:03 |
|* 1 | TABLE ACCESS FULL| T | 5 | 135 | 215 (3)| 00:00:03 |
--------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("OBJECT_NAME"='EMPLOYEES')
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
942 consistent gets
0 physical reads
0 redo size
538 bytes sent via SQL*Net to client
385 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
6 rows processed
不採用hint
SQL> select * from t where object_name='EMPLOYEES';
6 rows selected.
Execution Plan
----------------------------------------------------------
Plan hash value: 2869677071
--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 5 | 135 | 5 (0)| 00:00:01 |
|* 1 | INDEX SKIP SCAN | T_IND | 5 | 135 | 5 (0)| 00:00:01 |
--------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - access("OBJECT_NAME"='EMPLOYEES')
filter("OBJECT_NAME"='EMPLOYEES')
Statistics
----------------------------------------------------------
1 recursive calls
0 db block gets
17 consistent gets
1 physical reads
0 redo size
538 bytes sent via SQL*Net to client
385 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
6 rows processed
當全表掃描掃描了942個塊,聯合索引只掃描了17個資料塊。可以看到聯合索引的第一個欄位的值重複率很高時,即使謂詞中沒有聯合索引的第一個欄位,依然會使用index_ss
方式,效率遠遠高於全表掃描效率。但當第一個欄位的值重複率很低時,使用index_ss
的效率要低於 全表掃描,讀者可以自行實驗
和表的關聯相關的hint
/*+ leading(table_1,table_2) */
在多表關聯查詢中,指定哪個表作為驅動表,即告訴優化器首先要訪問哪個表上的資料。
select /*+ leading(t,t1) */ t.* from t,t1 where t.id=t1.id;
/*+ order */
讓Oracle根據from後面表的順序來選擇驅動表,oracle建議使用leading,他更為靈活
select /*+ order */ t.* from t,t1 where t.id=t1.id;
/*+ use_nl(table_1,table_2) */
在多表關聯查詢中,指定使用nest loops方式進行多表關聯。
select /*+ use_nl(t,t1) */ t.* from t,t1 where t.id=t1.id;
/*+ use_hash(table_1,table_2) */
在多表關聯查詢中,指定使用hash join方式進行多表關聯。
select /*+ use_hash(t,t1) */ t.* from t,t1 where t.id=t1.id;
在多表關聯查詢中,指定使用hash join方式進行多表關聯,並指定表t為驅動表。
select /*+ use_hash(t,t1) leading(t,t1) */ t.* from t,t1 where t.id=t1.id;
/*+ use_merge(table_1,table_2) */
在多表關聯查詢中,指定使用merge join方式進行多表關聯。
select /*+ use_merge(t,t1) */ t.* from t,t1 where t.id=t1.id;
/*+ no_use_nl(table_1,table_2) */
在多表關聯查詢中,指定不使用nest loops方式進行多表關聯。
select /*+ no_use_nl(t,t1) */ t.* from t,t1 where t.id=t1.id;
/*+ no_use_hash(table_1,table_2) */
在多表關聯查詢中,指定不使用hash join方式進行多表關聯。
select /*+ no_use_hash(t,t1) */ t.* from t,t1 where t.id=t1.id;
/*+ no_use_merge(table_1,table_2) */
在多表關聯查詢中,指定不使用merge join方式進行多表關聯。
select /*+ no_use_merge(t,t1) */ t.* from t,t1 where t.id=t1.id;
其他常用的hint
/*+ parallel(table_name n) */
在sql中指定執行的並行度,這個值將會覆蓋自身的並行度
select /*+ parallel(t 4) */ count(*) from t;
/*+ no_parallel(table_name) */
在sql中指定執行的不使用並行
select /*+ no_parallel(t) */ count(*) from t;
/*+ append */以直接載入的方式將資料載入入庫
insert into t /*+ append */ select * from t;
/*+ dynamic_sampling(table_name n) */
設定sql執行時動態採用的級別,這個級別為0~10
select /*+ dynamic_sampling(t 4) */ * from t where id > 1234
/*+ cache(table_name) */
進行全表掃描時將table置於LRU列表的最活躍端,類似於table的cache屬性
select /*+ full(employees) cache(employees) */ last_name from employees
附錄hint表格
Hints for Optimization Approaches and Goals | 詳細描述 |
---|---|
ALL_ROWS | The ALL_ROWS hint explicitly chooses the cost-based approach to optimize a statement block with a goal of best throughput (that is, minimum total resource consumption). |
FIRST_ROWS | The FIRST_ROWS hint explicitly chooses the cost-based approach to optimize a statement block with a goal of best response time (minimum resource usage to return first row). In newer Oracle version you should give a parameter with this hint: FIRST_ROWS(n) means that the optimizer will determine an executionplan to give a fast response for returning the first n rows. |
CHOOSE | The CHOOSE hint causes the optimizer to choose between the rule-based approach and the cost-based approach for a SQL statement based on the presence of statistics for the tables accessed by the statement |
RULE | The RULE hint explicitly chooses rule-based optimization for a statement block. This hint also causes the optimizer to ignore any other hints specified for the statement block. The RULE hint does not work any more in Oracle 10g. |
Hints for Access Paths | |
FULL | The FULL hint explicitly chooses a full table scan for the specified table. The syntax of the FULL hint is FULL(table) where table specifies the alias of the table (or table name if alias does not exist) on which the full table scan is to be performed. |
ROWID | The ROWID hint explicitly chooses a table scan by ROWID for the specified table. The syntax of the ROWID hint is ROWID(table) where table specifies the name or alias of the table on which the table access by ROWID is to be performed. (This hint depricated in Oracle 10g) |
CLUSTER | The CLUSTER hint explicitly chooses a cluster scan to access the specified table. The syntax of the CLUSTER hint is CLUSTER(table) where table specifies the name or alias of the table to be accessed by a cluster scan. |
HASH | The HASH hint explicitly chooses a hash scan to access the specified table. The syntax of the HASH hint is HASH(table) where table specifies the name or alias of the table to be accessed by a hash scan. |
HASH_AJ | The HASH_AJ hint transforms a NOT IN subquery into a hash anti-join to access the specified table. The syntax of the HASH_AJ hint is HASH_AJ(table) where table specifies the name or alias of the table to be accessed.(depricated in Oracle 10g) |
INDEX | The INDEX hint explicitly chooses an index scan for the specified table. The syntax of the INDEX hint is INDEX(table index) where:table specifies the name or alias of the table associated with the index to be scanned and index specifies an index on which an index scan is to be performed. This hint may optionally specify one or more indexes: |
NO_INDEX | The NO_INDEX hint explicitly disallows a set of indexes for the specified table. The syntax of the NO_INDEX hint is NO_INDEX(table index) |
INDEX_ASC | The INDEX_ASC hint explicitly chooses an index scan for the specified table. If the statement uses an index range scan, Oracle scans the index entries in ascending order of their indexed values. |
INDEX_COMBINE | If no indexes are given as arguments for the INDEX_COMBINE hint, the optimizer will use on the table whatever boolean combination of bitmap indexes has the best cost estimate. If certain indexes are given as arguments, the optimizer will try to use some boolean combination of those particular bitmap indexes. The syntax of INDEX_COMBINE is INDEX_COMBINE(table index). |
INDEX_JOIN | Explicitly instructs the optimizer to use an index join as an access path. For the hint to have a positive effect, a sufficiently small number of indexes must exist that contain all the columns required to resolve the query. |
INDEX_DESC | The INDEX_DESC hint explicitly chooses an index scan for the specified table. If the statement uses an index range scan, Oracle scans the index entries in descending order of their indexed values. |
INDEX_FFS | This hint causes a fast full index scan to be performed rather than a full table. |
NO_INDEX_FFS | Do not use fast full index scan (from Oracle 10g) |
INDEX_SS | Exclude range scan from query plan (from Oracle 10g) |
INDEX_SS_ASC | Exclude range scan from query plan (from Oracle 10g) |
INDEX_SS_DESC | Exclude range scan from query plan (from Oracle 10g) |
NO_INDEX_SS | The NO_INDEX_SS hint causes the optimizer to exclude a skip scan of the specified indexes on the specified table. (from Oracle 10g) |
Hints for Query Transformations | |
NO_QUERY_TRANSFORMATION | Prevents the optimizer performing query transformations. (from Oracle 10g) |
USE_CONCAT | The USE_CONCAT hint forces combined OR conditions in the WHERE clause of a query to be transformed into a compound query using the UNION ALL set operator. Normally, this transformation occurs only if the cost of the query using the concatenations is cheaper than the cost without them. |
NO_EXPAND | The NO_EXPAND hint prevents the optimizer from considering OR-expansion for queries having OR conditions or IN-lists in the WHERE clause. Usually, the optimizer considers using OR expansion and uses this method if it decides that the cost is lower than not using it. |
REWRITE | The REWRITE hint forces the optimizer to rewrite a query in terms of materialized views, when possible, without cost consideration. Use the REWRITE hint with or without a view list. If you use REWRITE with a view list and the list contains an eligible materialized view, then Oracle uses that view regardless of its cost. |
NOREWRITE / NO_REWRITE | In Oracle 10g renamed to NO_REWRITE. The NOREWRITE/NO_REWRITE hint disables query rewrite for the query block, overriding the setting of the parameter QUERY_REWRITE_ENABLED. |
MERGE | The MERGE hint lets you merge views in a query. |
NO_MERGE | The NO_MERGE hint causes Oracle not to merge mergeable views. This hint is most often used to reduce the number of possible permutations for a query and make optimization faster. |
FACT | The FACT hint indicated that the table should be considered as a fact table. This is used in the context of the star transformation. |
NO_FACT | The NO_FACT hint is used in the context of the star transformation to indicate to the transformation that the hinted table should not be considered as a fact table. |
STAR_TRANSFORMATION | The STAR_TRANSFORMATION hint makes the optimizer use the best plan in which the transformation has been used. Without the hint, the optimizer could make a query optimization decision to use the best plan generated without the transformation, instead of the best plan for the transformed query. |
NO_STAR_TRANSFORMATION | Do not use star transformation (from Oracle 10g) |
UNNEST | The UNNEST hint specifies subquery unnesting. |
NO_UNNEST | Use of the NO_UNNEST hint turns off unnesting for specific subquery blocks. |
Hints for Join Orders | |
LEADING | Give this hint to indicate the leading table in a join. This will indicate only 1 table. If you want to specify the whole order of tables, you can use the ORDERED hint. Syntax: LEADING(table) |
ORDERED | The ORDERED hint causes Oracle to join tables in the order in which they appear in the FROM clause. If you omit the ORDERED hint from a SQL statement performing a join , the optimizer chooses the order in which to join the tables. You may want to use the ORDERED hint to specify a join order if you know something about the number of rows selected from each table that the optimizer does not. Such information would allow you to choose an inner and outer table better than the optimizer could. |
Hints for Join Operations | |
USE_NL | The USE_NL hint causes Oracle to join each specified table to another row source with a nested loops join using the specified table as the inner table. The syntax of the USE_NL hint is USE_NL(table table) where table is the name or alias of a table to be used as the inner table of a nested loops join. |
NO_USE_NL | Do not use nested loop (from Oracle 10g) |
USE_NL_WITH_INDEX | Specifies a nested loops join. (from Oracle 10g) |
USE_MERGE | The USE_MERGE hint causes Oracle to join each specified table with another row source with a sort-merge join. The syntax of the USE_MERGE hint is USE_MERGE(table table) where table is a table to be joined to the row source resulting from joining the previous tables in the join order using a sort-merge join. |
NO_USE_MERGE | Do not use merge (from Oracle 10g) |
USE_HASH | The USE_HASH hint causes Oracle to join each specified table with another row source with a hash join. The syntax of the USE_HASH hint is USE_HASH(table table) where table is a table to be joined to the row source resulting from joining the previous tables in the join order using a hash join. |
NO_USE_HASH | Do not use hash (from Oracle 10g) |
Hints for Parallel Execution | |
PARALLEL | The PARALLEL hint allows you to specify the desired number of concurrent query servers that can be used for the query. The syntax is PARALLEL(table number number). The PARALLEL hint must use the table alias if an alias is specified in the query. The PARALLEL hint can then take two values separated by commas after the table name. The first value specifies the degree of parallelism for the given table, the second value specifies how the table is to be split among the instances of a parallel server. Specifying DEFAULT or no value signifies the query coordinator should examine the settings of the initialization parameters (described in a later section) to determine the default degree of parallelism. |
NOPARALLEL / NO_PARALLEL | The NOPARALLEL hint allows you to disable parallel scanning of a table, even if the table was created with a PARALLEL clause. In Oracle 10g this hint was renamed to NO_PARALLEL. |
PQ_DISTRIBUTE | The PQ_DISTRIBUTE hint improves the performance of parallel join operations. Do this by specifying how rows of joined tables should be distributed among producer and consumer query servers. Using this hint overrides decisions the optimizer would normally make. |
NO_PARALLEL_INDEX | The NO_PARALLEL_INDEX hint overrides a PARALLEL attribute setting on an index to avoid a parallel index scan operation. |
Additional Hints | |
APPEND | When the APPEND hint is used with the INSERT statement, data is appended to the table. Existing free space in the block is not used. If a table or an index is specified with nologging, this hint applied with an insert statement produces a direct path insert which reduces generation of redo. |
NOAPPEND | Overrides the append mode. |
CACHE | The CACHE hint specifies that the blocks retrieved for the table in the hint are placed at the most recently used end of the LRU list in the buffer cache when a full table scan is performed. This option is useful for small lookup tables. In the following example, the CACHE hint overrides the table default caching specification. |
NOCACHE | The NOCACHE hint specifies that the blocks retrieved for this table are placed at the least recently used end of the LRU list in the buffer cache when a full table scan is performed. This is the normal behavior of blocks in the buffer cache. |
PUSH_PRED | The PUSH_PRED hint forces pushing of a join predicate into the view. |
NO_PUSH_PRED | The NO_PUSH_PRED hint prevents pushing of a join predicate into the view. |
PUSH_SUBQ | The PUSH_SUBQ hint causes nonmerged subqueries to be evaluated at the earliest possible place in the execution plan. |
NO_PUSH_SUBQ | The NO_PUSH_SUBQ hint causes non-merged subqueries to be evaluated as the last step in the execution plan. |
QB_NAME | Specifies a name for a query block. (from Oracle 10g) |
CURSOR_SHARING_EXACT | Oracle can replace literals in SQL statements with bind variables, if it is safe to do so. This is controlled with the CURSOR_SHARING startup parameter. The CURSOR_SHARING_EXACT hint causes this behavior to be switched off. In other words, Oracle executes the SQL statement without any attempt to replace literals by bind variables. |
DRIVING_SITE | The DRIVING_SITE hint forces query execution to be done for the table at a different site than that selected by Oracle |
DYNAMIC_SAMPLING | The DYNAMIC_SAMPLING hint lets you control dynamic sampling to improve server performance by determining more accurate predicate selectivity and statistics for tables and indexes. You can set the value of DYNAMIC_SAMPLING to a value from 0 to 10. The higher the level, the more effort the compiler puts into dynamic sampling and the more broadly it is applied. Sampling defaults to cursor level unless you specify a table. |
SPREAD_MIN_ANALYSIS | This hint omits some of the compile time optimizations of the rules, mainly detailed dependency graph analysis, on spreadsheets. Some optimizations such as creating filters to selectively populate spreadsheet access structures and limited rule pruning are still used. (from Oracle 10g) |
Hints with unknown status | |
MERGE_AJ | The MERGE_AJ hint transforms a NOT IN subquery into a merge anti-join to access the specified table. The syntax of the MERGE_AJ hint is MERGE_AJ(table) where table specifies the name or alias of the table to be accessed.(depricated in Oracle 10g) |
AND_EQUAL | The AND_EQUAL hint explicitly chooses an execution plan that uses an access path that merges the scans on several single-column indexes. The syntax of the AND_EQUAL hint is AND_EQUAL(table index index) where table specifies the name or alias of the table associated with the indexes to be merged. and index specifies an index on which an index scan is to be performed. You must specify at least two indexes. You cannot specify more than five. (depricated in Oracle 10g) |
STAR | The STAR hint forces the large table to be joined last using a nested loops join on the index. The optimizer will consider different permutations of the small tables. (depricated in Oracle 10g) |
BITMAP | Usage: BITMAP(table_name index_name) Uses a bitmap index to access the table. (depricated ?) |
HASH_SJ | Use a Hash Anti-Join to evaluate a NOT IN sub-query. Use this hint in the sub-query, not in the main query. Use this when your high volume NOT IN sub-query is using a FILTER or NESTED LOOPS join. Try MERGE_AJ if HASH_AJ refuses to work.(depricated in Oracle 10g) |
NL_SJ | Use a Nested Loop in a sub-query. (depricated in Oracle 10g) |
NL_AJ | Use an anti-join in a sub-query. (depricated in Oracle 10g) |
ORDERED_PREDICATES | (depricated in Oracle 10g) |
EXPAND_GSET_TO_UNION | (depricated in Oracle 10g) |
相關文章
- [原創]append_values hintAPP
- (原創)建立windows域—深入理解域概念薦Windows
- 【原創】ORACLE 深入解析10053事件Oracle事件
- 深入理解Oracle中的DBCAOracle
- 深入理解Oracle中的MutexOracleMutex
- 深入理解Oracle中的latchOracle
- Oracle中Hint隨記Oracle
- Oracle中的sql hintOracleSQL
- Oracle中“HINT”的使用方法Oracle
- oracle hintOracle
- 【原創】說說你是如何理解Oracle資料庫中latch和enqueue lock的?Oracle資料庫ENQ
- ORACLE 部分HINTOracle
- oracle hint (續)Oracle
- Oracle Hint 精華Oracle
- 深入理解Oracle ExadataOracle
- 【TUNE_ORACLE】Oracle Hint之常用Hint功能概述(五)Oracle
- 【TUNE_ORACLE】Oracle Hint之常用Hint功能概述(四)Oracle
- 【TUNE_ORACLE】Oracle Hint之常用Hint功能概述(三)Oracle
- 【TUNE_ORACLE】Oracle Hint之常用Hint功能概述(二)Oracle
- 【TUNE_ORACLE】Oracle Hint之常用Hint功能概述(一)Oracle
- 深入理解計算機中的原碼、補碼、反碼計算機
- oracle之hint概述Oracle
- oracle常見hintOracle
- oracle hint簡述Oracle
- oracle hint (續-0)Oracle
- oracle hint_no_indexOracleIndex
- Oracle Hint 精華文章Oracle
- 常用的Oracle HintOracle
- Oracle Hint 詳解Oracle
- Oracle Hint的用法Oracle
- JS中this的深入理解JS
- 深入理解Js中的thisJS
- ORACLE鎖機制深入理解Oracle
- [原創]深入掌握JMS(四):實戰Queue
- [原創]深入掌握JMS(五):實戰Topic
- [原創]深入掌握JMS(七):DeliveryMode例子
- oracle hint之hint_index_ffs,index_joinOracleIndex
- 【原創】Oracle 高可用概述Oracle