Oracle優化器的RBO和CBO方式
Oracle的優化器的RBO和CBO方式
1、基於規則的優化方式(Rule-Based Optimization,簡稱為RBO)
優化器在分析SQL語句時,所遵循的是Oracle內部預定的一些規則,對資料是不敏感的。它只借助少量的資訊來決定一個sql語句的執行計劃,包括:
1)sql語句本身
2)sql中涉及到的table、view、index等的基本資訊
3)本地資料庫中資料字典中的資訊(遠端資料庫資料字典資訊對RBO是無效的)
例如:我們常見的,當一個where子句中的一列有索引時去走索引。但是需要注意,走索引不一定就是優的,比如一個表只有兩行資料,一次IO就可以完成全表的檢索,而此時走索引時則需要兩次IO,這時全表掃描(full table scan)的效率更優。
2、基於代價的優化方式(Cost-Based Optimization,簡稱為CBO)
它是看語句的代價(Cost),通過代價引擎來估計每個執行計劃所需的代價,該代價將每個執行計劃所耗費的資源進行量化,CBO根據這個代價選擇出最優的執行計劃。一個查詢所耗費的資源可分為三部分:I/O代價、CPU代價、NETWORK代價。I/O是指把資料從磁碟讀入記憶體時所需代價(該代價是查詢所需最主要的,所以在優化時一個基本原則就是降低I/O總次數);CPU代價是指處理記憶體中資料所需的代價,資料一旦讀入記憶體,當我們識別出我們所要的資料後,會在這些資料上執行排序(sort)或連線(join)操作,這需要消耗CPU資源;對於訪問遠端節點來說,network代價的花費也是很大的。
優化器在判斷是否用這種方式時,主要參照的是表及索引的統計資訊。統計資訊給出表的大小、有多少行、每行的長度等資訊。這些統計資訊起初在庫內是沒有的,是做analyze後才出現的,很多的時侯過期統計資訊會令優化器做出一個錯誤的執行計劃,因些應及時更新這些資訊(dbms_stat.analyze)。
如星型連線排列查詢,雜湊連線查詢,函式索引,和並行查詢等一些技術都是基於CBD的。
3、優化模式包括Rule、Choose、First rows、All rows四種方式:
Rule:基於規則的方式。
Choolse:預設的情況下Oracle用的便是這種方式。指的是當一個表或或索引有統計資訊,則走CBO的方式,如果表或索引沒統計資訊,表又不是特別的小,而且相應的列有索引時,那麼就走索引,走RBO的方式。
First Rows:它與Choose方式是類似的,所不同的是當一個表有統計資訊時,它將是以最快的方式返回查詢的最先的幾行,從總體上減少了響應時間。
All Rows:也就是我們所說的Cost的方式,當一個表有統計資訊時,它將以最快的方式返回表的所有的行,從總體上提高查詢的吞吐量。沒有統計資訊則走RBO的方式。
4、設定選用哪種優化模式:
A、在initSID.ora中設定OPTIMIZER_MODE=RULE/CHOOSE/FIRST_ROWS/ALL_ROWS(預設是Choose)
B、Sessions級別通過:ALTER SESSION SET OPTIMIZER_MODE=RULE/CHOOSE/FIRST_ROWS/ALL_ROWS
C、語句級別用Hint(/*+ ... */)來設定
5、一些常見的問題:
A、為什麼表的某個欄位明明有索引,但執行計劃卻不走索引?
1、優化模式是all_rows的方式
2、表作過analyze,有統計資訊
3、表很小,上文提到過的,Oracle的優化器認為不值得走索引。
B、使用CBO時,SQL語句中為什麼不能引用系統資料字典表或檢視?
1、因為系統資料字典表都未被分析過,可能導致極差的“執行計劃”。
2、擅自對資料字典表做分析,可能導致死鎖,或系統效能嚴重下降。
C、使用CBO時如何選擇表連線方式?
1、CBO有時會偏重於SMJ和HJ,但在OLTP系統中,NL一般會更好,因為它高效的使用了索引。
2、SMJ即使相關列上建有索引,最多隻能因索引的存在,避免資料排序過程。
3、HJ由於須做HASH運算,索引的存在對資料查詢速度幾乎沒有影響。
D、使用CBO時,需要注意什麼嗎?
1、必須保證為表和相關的索引蒐集足夠的統計資料, 對資料經常有增、刪、改的表最好定期對錶和索引進行分析
2、可用SQL語句:analyze table xxx compute statistics for all indexes
E、為什麼有時使用CBO會比較慢?
1、沒有對錶或檢視進行Analyze
2、SQL進行CBO時對於沒有Analyze的物件會自動進行Analyze,因此造成執行緩慢
1、基於規則的優化方式(Rule-Based Optimization,簡稱為RBO)
優化器在分析SQL語句時,所遵循的是Oracle內部預定的一些規則,對資料是不敏感的。它只借助少量的資訊來決定一個sql語句的執行計劃,包括:
1)sql語句本身
2)sql中涉及到的table、view、index等的基本資訊
3)本地資料庫中資料字典中的資訊(遠端資料庫資料字典資訊對RBO是無效的)
例如:我們常見的,當一個where子句中的一列有索引時去走索引。但是需要注意,走索引不一定就是優的,比如一個表只有兩行資料,一次IO就可以完成全表的檢索,而此時走索引時則需要兩次IO,這時全表掃描(full table scan)的效率更優。
2、基於代價的優化方式(Cost-Based Optimization,簡稱為CBO)
它是看語句的代價(Cost),通過代價引擎來估計每個執行計劃所需的代價,該代價將每個執行計劃所耗費的資源進行量化,CBO根據這個代價選擇出最優的執行計劃。一個查詢所耗費的資源可分為三部分:I/O代價、CPU代價、NETWORK代價。I/O是指把資料從磁碟讀入記憶體時所需代價(該代價是查詢所需最主要的,所以在優化時一個基本原則就是降低I/O總次數);CPU代價是指處理記憶體中資料所需的代價,資料一旦讀入記憶體,當我們識別出我們所要的資料後,會在這些資料上執行排序(sort)或連線(join)操作,這需要消耗CPU資源;對於訪問遠端節點來說,network代價的花費也是很大的。
優化器在判斷是否用這種方式時,主要參照的是表及索引的統計資訊。統計資訊給出表的大小、有多少行、每行的長度等資訊。這些統計資訊起初在庫內是沒有的,是做analyze後才出現的,很多的時侯過期統計資訊會令優化器做出一個錯誤的執行計劃,因些應及時更新這些資訊(dbms_stat.analyze)。
如星型連線排列查詢,雜湊連線查詢,函式索引,和並行查詢等一些技術都是基於CBD的。
3、優化模式包括Rule、Choose、First rows、All rows四種方式:
Rule:基於規則的方式。
Choolse:預設的情況下Oracle用的便是這種方式。指的是當一個表或或索引有統計資訊,則走CBO的方式,如果表或索引沒統計資訊,表又不是特別的小,而且相應的列有索引時,那麼就走索引,走RBO的方式。
First Rows:它與Choose方式是類似的,所不同的是當一個表有統計資訊時,它將是以最快的方式返回查詢的最先的幾行,從總體上減少了響應時間。
All Rows:也就是我們所說的Cost的方式,當一個表有統計資訊時,它將以最快的方式返回表的所有的行,從總體上提高查詢的吞吐量。沒有統計資訊則走RBO的方式。
4、設定選用哪種優化模式:
A、在initSID.ora中設定OPTIMIZER_MODE=RULE/CHOOSE/FIRST_ROWS/ALL_ROWS(預設是Choose)
B、Sessions級別通過:ALTER SESSION SET OPTIMIZER_MODE=RULE/CHOOSE/FIRST_ROWS/ALL_ROWS
C、語句級別用Hint(/*+ ... */)來設定
5、一些常見的問題:
A、為什麼表的某個欄位明明有索引,但執行計劃卻不走索引?
1、優化模式是all_rows的方式
2、表作過analyze,有統計資訊
3、表很小,上文提到過的,Oracle的優化器認為不值得走索引。
B、使用CBO時,SQL語句中為什麼不能引用系統資料字典表或檢視?
1、因為系統資料字典表都未被分析過,可能導致極差的“執行計劃”。
2、擅自對資料字典表做分析,可能導致死鎖,或系統效能嚴重下降。
C、使用CBO時如何選擇表連線方式?
1、CBO有時會偏重於SMJ和HJ,但在OLTP系統中,NL一般會更好,因為它高效的使用了索引。
2、SMJ即使相關列上建有索引,最多隻能因索引的存在,避免資料排序過程。
3、HJ由於須做HASH運算,索引的存在對資料查詢速度幾乎沒有影響。
D、使用CBO時,需要注意什麼嗎?
1、必須保證為表和相關的索引蒐集足夠的統計資料, 對資料經常有增、刪、改的表最好定期對錶和索引進行分析
2、可用SQL語句:analyze table xxx compute statistics for all indexes
E、為什麼有時使用CBO會比較慢?
1、沒有對錶或檢視進行Analyze
2、SQL進行CBO時對於沒有Analyze的物件會自動進行Analyze,因此造成執行緩慢
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/16978544/viewspace-701735/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- SQL優化器-RBO與CBO分別是什麼SQL優化
- Oracle:RBOOracle
- 最佳化器-RBO 的規則轉化
- Oracle "腦殘" CBO 最佳化案例Oracle
- Oracle優化案例-改變那些CBO無能為力的執行計劃(一)Oracle優化
- Hive使用Calcite CBO優化流程及SQL優化實戰Hive優化SQL
- Spark SQL 效能優化再進一步 CBO 基於代價的優化SparkSQL優化
- 【Oracle】Oracle wrong result一則(優化器問題)Oracle優化
- Oracle優化的方法Oracle優化
- 袋鼠雲數棧基於CBO在Spark SQL優化上的探索SparkSQL優化
- oracle優化Oracle優化
- 深入淺出Calcite與SQL CBO(Cost-Based Optimizer)優化SQL優化
- oracle優化技巧Oracle優化
- oracle EM 優化Oracle優化
- oracle 效能優化Oracle優化
- Oracle效能優化使用度量和預警Oracle優化
- Oracle效能優化-SQL優化(案例一)Oracle優化SQL
- Oracle效能優化-SQL優化(案例二)Oracle優化SQL
- Oracle效能優化-SQL優化(案例三)Oracle優化SQL
- Oracle效能優化-SQL優化(案例四)Oracle優化SQL
- 如何調優 Oracle SQL系列文章:查詢優化器介紹OracleSQL優化
- 使用資源管理器優化Oracle效能AQ優化Oracle
- SQL優化案例-改變那些CBO無能為力的執行計劃(一)SQL優化
- Oracle in 查詢優化Oracle優化
- 【OPTIMIZATION】Oracle影響優化器選擇的相關技術Oracle優化
- 【DBMS_STATUS】Oracle控制優化器統計資訊的使用Oracle優化
- Oracle優化案例-使用with as優化Subquery Unnesting(七)Oracle優化
- Oracle優化案例-單表分頁語句的優化(八)Oracle優化
- Oracle 效能優化-expdp備份速度優化02Oracle優化
- Oracle 效能優化-expdp備份速度優化03Oracle優化
- Oracle優化案例-(三十四)Oracle優化
- Oracle優化案例-儲存過程的優化思路(二十三)Oracle優化儲存過程
- 一次Oracle優化所想到的Oracle優化
- 【STATS】Oracle匯入匯出優化器統計資訊Oracle優化
- 資料庫應用優化(二)伺服器和配置優化資料庫優化伺服器
- 轉:ORACLE的JDBC連線方式:OCI和THINOracleJDBC
- ORACLE 12C 優化器的一些新特性總結(二)Oracle優化
- ORACLE 12C 優化器的一些新特性總結(一)Oracle優化
- oracle全文索引之同步和優化索引做了什麼Oracle索引優化