ORACLE優化器RBO與CBO介紹總結
RBO和CBO的基本概念 算法
Oracle數據庫中的優化器又叫查詢優化器（Query Optimizer）。它是SQL分析和執行的優化工具，它負責生成、制定SQL的執行計劃。Oracle的優化器有兩種，基於規則的優化器（RBO）與基於代價的優化器（CBO) 數據庫
RBO: Rule-Based Optimization 基於規則的優化器 session
CBO: Cost-Based Optimization 基於代價的優化器 oracle
RBO自ORACLE 6以來被採用，一直沿用至ORACLE 9i. ORACLE 10g開始，ORACLE已經完全丟棄了RBO，它有着一套嚴格的使用規則，只要你按照它去寫SQL語句，不管數據表中的內容怎樣，也不會影響到你的「執行計劃」，也就是說RBO對數據不「敏感」；它根據ORACLE指定的優先順序規則，對指定的表進行執行計劃的選擇。好比在規則中，索引的優先級大於全表掃描;RBO是根據可用的訪問路徑以及訪問路徑等級來選擇執行計劃，在RBO中，SQL的寫法每每會影響執行計劃，它要求開發人員很是瞭解RBO的各項細則，菜鳥寫出來的SQL腳本性能可能很是差。隨着RBO的被遺棄，漸漸不爲人所知。也許只有老一輩的DBA對其瞭解得比較深刻。關於RBO的訪問路徑，官方文檔作了詳細介紹： app
RBO Path 1: Single Row by Rowid ide
RBO Path 2: Single Row by Cluster Join 工具
RBO Path 3: Single Row by Hash Cluster Key with Unique or Primary Key 性能
RBO Path 4: Single Row by Unique or Primary Key 測試
RBO Path 5: Clustered Join 大數據
RBO Path 7: Indexed Cluster Key
RBO Path 9: Single-Column Indexes
RBO Path 10: Bounded Range Search on Indexed Columns
RBO Path 11: Unbounded Range Search on Indexed Columns
RBO Path 13: MAX or MIN of Indexed Column
RBO Path 14: ORDER BY on Indexed Column
CBO是一種比RBO更加合理、可靠的優化器，它是從ORACLE 8中開始引入，但到ORACLE 9i 中才逐漸成熟，在ORACLE 10g中徹底取代RBO， CBO是計算各類可能「執行計劃」的「代價」，即COST，從中選用COST最低的執行方案，做爲實際運行方案。它依賴數據庫對象的統計信息，統計信息的準確與否會影響CBO作出最優的選擇。若是對一次執行SQL時發現涉及對象（表、索引等）沒有被分析、統計過，那麼ORACLE會採用一種叫作動態採樣的技術，動態的收集表和索引上的一些數據信息。
關於RBO與CBO，我有個形象的比喻：大數據時代到來之前，作生意或許憑藉多年累計下來的經驗（RBO）就可以很好的作出決策，跟隨市場變化。可是大數據時代，若是作生意仍是靠之前憑經驗作決策，而不是靠大數據、數據分析、數據挖掘作決策，那麼就有可能作出錯誤的決策。這也就是愈來愈多的公司對BI、數據挖掘愈來愈重視的緣故，像電商、遊戲、電信等行業都已經大規模的應用，之前在一家遊戲公司數據庫部門作BI分析，挖掘潛在消費用戶簡直無所不及。至今映像頗深。
CBO與RBO的優劣
CBO優於RBO是由於RBO是一種呆板、過期的優化器，它只認規則，對數據不敏感。畢竟規則是死的，數據是變化的，這樣生成的執行計劃每每是不可靠的，不是最優的，CBO因爲RBO能夠從不少方面體現。下面請看一個例子，此案例來自於《讓Oracle跑得更快》。
SQL> create table test as select 1 id ,object_name from dba_objects;
Table created.
SQL> create index idx_test on test(id);
Index created.
SQL> update test set id=100 where rownum =1;
1 row updated.
SQL> select id, count(1) from test group by id;
ID COUNT(1)
---------- ----------
100 1
1 50314
從上面能夠看出，該測試表的數據分佈極其不均衡,ID=100的記錄只有一條，而ID=1的記錄有50314條。咱們先看看RBO下兩條SQL的執行計劃.
SQL> select /*+ rule */ * from test where id =100;
Execution Plan
----------------------------------------------------------
Plan hash value: 2473784974
------------------------------------------------
| Id | Operation | Name |
------------------------------------------------
| 0 | SELECT STATEMENT | |
| 1 | TABLE ACCESS BY INDEX ROWID| TEST |
|* 2 | INDEX RANGE SCAN | IDX_TEST |
------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("ID"=100)
Note
-----
- rule based optimizer used (consider using cbo)
Statistics
----------------------------------------------------------
1 recursive calls
0 db block gets
3 consistent gets
0 physical reads
0 redo size
588 bytes sent via SQL*Net to client
469 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
SQL>
SQL> select /*+ rule */ * from test where id=1;
50314 rows selected.
Execution Plan
----------------------------------------------------------
Plan hash value: 2473784974
------------------------------------------------
| Id | Operation | Name |
------------------------------------------------
| 0 | SELECT STATEMENT | |
| 1 | TABLE ACCESS BY INDEX ROWID| TEST |
|* 2 | INDEX RANGE SCAN | IDX_TEST |
------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("ID"=1)
Note
-----
- rule based optimizer used (consider using cbo)
Statistics
----------------------------------------------------------
1 recursive calls
0 db block gets
7012 consistent gets
97 physical reads
0 redo size
2243353 bytes sent via SQL*Net to client
37363 bytes received via SQL*Net from client
3356 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
50314 rows processed
從執行計劃能夠看出，RBO的執行計劃讓人有點失望，對於ID=1，幾乎全部的數據所有符合謂詞條件，走索引只能增長額外的開銷（由於ORACLE首先要訪問索引數據塊，在索引上找到了對應的鍵值，而後按照鍵值上的ROWID再去訪問表中相應數據），既然咱們幾乎要訪問全部表中的數據，那麼全表掃描天然是最優的選擇。而RBO選擇了錯誤的執行計劃。能夠對比一下CBO下SQL的執行計劃，顯然它對數據敏感，執行計劃及時的根據數據量作了調整,當查詢條件爲1時，它走全表掃描；當查詢條件爲100時，它走區間索引掃描。以下所示：
SQL> select * from test where id=1;
50314 rows selected.
Execution Plan
----------------------------------------------------------
Plan hash value: 1357081020
--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 49075 | 3786K| 52 (2)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| TEST | 49075 | 3786K| 52 (2)| 00:00:01 |
--------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("ID"=1)
Note
-----
- dynamic sampling used for this statement
Statistics
----------------------------------------------------------
32 recursive calls
0 db block gets
3644 consistent gets
0 physical reads
0 redo size
1689175 bytes sent via SQL*Net to client
37363 bytes received via SQL*Net from client
3356 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
50314 rows processed
SQL> select * from test where id =100;
Execution Plan
----------------------------------------------------------
Plan hash value: 2473784974
----------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 79 | 2 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| TEST | 1 | 79 | 2 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | IDX_TEST | 1 | | 1 (0)| 00:00:01 |
----------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("ID"=100)
Note
-----
- dynamic sampling used for this statement
Statistics
----------------------------------------------------------
9 recursive calls
0 db block gets
73 consistent gets
0 physical reads
0 redo size
588 bytes sent via SQL*Net to client
469 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
SQL>
僅此一項就能夠看出爲何ORACLE極力推薦使用CBO，從ORACLE 10g開始不支持RBO的緣故。所謂長江後浪推前浪，前浪死在沙灘上。
CBO知識點的總結
CBO優化器根據SQL語句生成一組可能被使用的執行計劃，估算出每一個執行計劃的代價，並調用計劃生成器（Plan Generator）生成執行計劃，比較執行計劃的代價，最終選擇選擇一個代價最小的執行計劃。查詢優化器由查詢轉換器（Query Transform）、代價估算器（Estimator）和計劃生成器（Plan Generator）組成。
CBO優化器組件
CBO由如下組件構成：
· 查詢轉化器（Query Transformer）
查詢轉換器的做用就是等價改變查詢語句的形式，以便產生更好的執行計劃。它決定是否重寫用戶的查詢（包括視圖合併、謂詞推動、非嵌套子查詢/子查詢反嵌套、物化視圖重寫），以生成更好的查詢計劃。
The input to the query transformer is a parsed query, which is represented by a set of
query blocks. The query blocks are nested or interrelated to each other. The form of the
query determines how the query blocks are interrelated to each other. The main
objective of the query transformer is to determine if it is advantageous to change the
form of the query so that it enables generation of a better query plan. Several different
query transformation techniques are employed by the query transformer, including:
■ View Merging
■ Predicate Pushing
■ Subquery Unnesting
■ Query Rewrite with Materialized Views
Any combination of these transformations can be applied to a given query.
· 代價評估器（Estimator）
評估器經過複雜的算法結合來統計信息的三個值來評估各個執行計劃的整體成本：選擇性（Selectivity）、基數（Cardinality）、成本（Cost）
計劃生成器會考慮可能的訪問路徑（Access Path）、關聯方法和關聯順序，生成不一樣的執行計劃，讓查詢優化器從這些計劃中選擇出執行代價最小的一個計劃。
· 計劃生成器（Plan Generator）
計劃生成器就是生成大量的執行計劃，而後選擇其整體代價或整體成本最低的一個執行計劃。
因爲不一樣的訪問路徑、鏈接方式和鏈接順序能夠組合，雖然以不一樣的方式訪問和處理數據，可是能夠產生一樣的結果
下圖是我本身爲了加深理解，用工具畫的圖
查看ORACLE優化器
SQL> show parameter optimizer_mode;
NAME TYPE VALUE
--------------------------- ----------- -----------------
optimizer_mode string ALL_ROWS
修改ORACLE優化器
ORACLE 10g 優化器能夠從系統級別、會話級別、語句級別三種方式修改優化器模式，很是方便靈活。
其中optimizer_mode能夠選擇的值有： first_rows_n,all_rows. 其中first_rows_n又有first_rows_1000, first_rows_100, first_rows_10, first_rows_1
在Oracle 9i中，優化器模式能夠選擇first_rows_n,all_rows, choose, rule 等模式：
Rule： 基於規則的方式。
Choolse：指的是當一個表或或索引有統計信息，則走CBO的方式，若是表或索引沒統計信息，表又不是特別的小，並且相應的列有索引時，那麼就走索引，走RBO的方式。
If OPTIMIZER_MODE=CHOOSE, if statistics do not exist, and if you do not add hints to SQL statements, then SQL statements use the RBO. You can use the RBO to access both relational data and object types. If OPTIMIZER_MODE=FIRST_ROWS, FIRST_ROWS_n, or ALL_ROWS and no statistics exist, then the CBO uses default statistics. Migrate existing applications to use the cost-based approach.
First Rows：它與Choose方式是相似的，所不一樣的是當一個表有統計信息時，它將是以最快的方式返回查詢的最早的幾行，從整體上減小了響應時間。
All Rows: 10g中的默認值，也就是咱們所說的Cost的方式，當一個表有統計信息時，它將以最快的方式返回表的全部的行，從整體上提升查詢的吞吐
雖然Oracle 10g中再也不支持RBO，Oracle 10g官方文檔關於optimizer_mode參數的只有first_rows和all_rows.可是依然能夠設置 optimizer_mode爲rule或choose，估計是ORACLE爲了過渡或向下兼容考慮。以下所示。
系統級別
SQL> alter system set optimizer_mode=rule scope=both;
System altered.
SQL> show parameter optimizer_mode
NAME TYPE VALUE
-------------------------------- ----------- -----------------------
optimizer_mode string RULE
會話級別
會話級別修改優化器模式，只對當前會話有效，其它會話依然使用系統優化器模式。
SQL> alter session set optimizer_mode=first_rows_100;
Session altered.
語句級別
語句級別經過使用提示hints來實現。
SQL> select /*+ rule */ * from dba_objects where rownum <= 10;
- 1. ORACLE優化器RBO與CBO介紹總結
- 2. Oracle中的優化器--CBO和RBO
- 3. Oracle的優化器的RBO和CBO方式
- 4. 基於CBO的優化器
- 5. RBO和CBO的基本概念
- 6. RBO基於規則的優化器！
- 7. CBO優化器實用理解
- 8. Gulp介紹與Hexo優化
- 9. 優化器（Optimizer）介紹
- 10. webpack4介紹與總結
- 更多相關文章...
- • SEO - 搜索引擎優化 - 網站建設指南
- • 網站主機 介紹 - 網站主機教程
- • Java Agent入門實戰（一）-Instrumentation介紹與使用
- • 算法總結-廣度優先算法
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. Window下Ribbit MQ安裝
- 2. Linux下Redis安裝及集羣搭建
- 3. shiny搭建網站填坑戰略
- 4. Mysql8.0.22安裝與配置詳細教程
- 5. Hadoop安裝及配置
- 6. Python爬蟲初學筆記
- 7. 部署LVS-Keepalived高可用集羣
- 8. keepalived+mysql高可用集羣
- 9. jenkins 公鑰配置
- 10. HA實用詳解
- 1. ORACLE優化器RBO與CBO介紹總結
- 2. Oracle中的優化器--CBO和RBO
- 3. Oracle的優化器的RBO和CBO方式
- 4. 基於CBO的優化器
- 5. RBO和CBO的基本概念
- 6. RBO基於規則的優化器！
- 7. CBO優化器實用理解
- 8. Gulp介紹與Hexo優化
- 9. 優化器（Optimizer）介紹
- 10. webpack4介紹與總結