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，因此造成運行緩慢
優化器在分析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，因此造成運行緩慢