一、基於規則的優化方式(Rule-Based Optimization,簡稱爲RBO)
優化器在分析SQL語句時,所遵循的是Oracle內部預約的一些規則,對數據是不敏感的。它只借助少許的信息來決定一個sql語句的執行計劃,包括:
1)sql語句自己
2)sql中涉及到的table、view、index等的基本信息
3)本地數據庫中數據字典中的信息(遠程數據庫數據字典信息對RBO是無效的)
例如:咱們常見的,當一個where子句中的一列有索引時去走索引。可是須要注意,走索引不必定就是優的,好比一個表只有兩行數據,一次IO就能夠完成全表的檢索,而此時走索引時則須要兩次IO,這時全表掃描(full table scan)的效率更優。
二、基於代價的優化方式(Cost-Based Optimization,簡稱爲CBO)
它是看語句的代價(Cost),經過代價引擎來估計每一個執行計劃所需的代價,該代價將每一個執行計劃所耗費的資源進行量化,CBO根據這個代價選擇出最優的執行計劃。一個查詢所耗費的資源可分爲三部分:
I/O代價、CPU代價、NETWORK代價。I/O是指把數據從磁盤讀入內存時所需代價(該代價是查詢所需最主要的,因此在優化時一個基本原則就是下降I/O總次數);CPU代價是指處理內存中數據所需的代價,數據一旦讀入內存,當咱們識別出咱們所要的數據後,會在這些數據上執行排序(sort)或鏈接(join)操做,這須要消耗CPU資源;對於訪問遠程節點來講,network代價的花費也是很大的。
優化器在判斷是否用這種方式時,主要參照的是表及索引的統計信息。統計信息給出表的大小、有多少行、每行的長度等信息。這些統計信息起初在庫內是沒有的,是作analyze後纔出現的,不少的時侯過時統計信息會令優化器作出一個錯誤的執行計劃,因些應及時更新這些信息(dbms_stat.analyze)。
如星型鏈接排列查詢,哈希鏈接查詢,函數索引,和並行查詢等一些技術都是基於CBD的。
三、優化模式包括Rule、Choose、First rows、All rows四種方式:
Rule:基於規則的方式。
Choolse:默認的狀況下Oracle用的即是這種方式。指的是當一個表或或索引有統計信息,則走CBO的方式,若是表或索引沒統計信息,表又不是特別的小,並且相應的列有索引時,那麼就走索引,走RBO的方式。
First Rows:它與Choose方式是相似的,所不一樣的是當一個表有統計信息時,它將是以最快的方式返回查詢的最早的幾行,從整體上減小了響應時間。
All Rows:也就是咱們所說的Cost的方式,當一個表有統計信息時,它將以最快的方式返回表的全部的行,從整體上提升查詢的吞吐量。沒有統計信息則走RBO的方式。
四、設定選用哪一種優化模式:
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(/*+ ... */)來設定
五、一些常見的問題:
A、爲何表的某個字段明明有索引,但執行計劃卻不走索引?
一、優化模式是all_rows的方式
二、表做過analyze,有統計信息
三、表很小,上文提到過的,Oracle的優化器認爲不值得走索引。
B、使用CBO時,SQL語句中爲何不能引用系統數據字典表或視圖?
一、由於系統數據字典表都未被分析過,可能致使極差的「執行計劃」。
二、擅自對數據字典表作分析,可能致使死鎖,或系統性能嚴重降低。
C、使用CBO時如何選擇錶鏈接方式?
一、CBO有時會偏重於SMJ和HJ,但在OLTP系統中,NL通常會更好,由於它高效的使用了索引。
二、SMJ即便相關列上建有索引,最多隻能因索引的存在,避免數據排序過程。
三、HJ因爲須作HASH運算,索引的存在對數據查詢速度幾乎沒有影響。
D、使用CBO時,須要注意什麼嗎?
一、必須保證爲表和相關的索引蒐集足夠的統計數據, 對數據常常有增、刪、改的表最好按期對錶和索引進行分析
二、可用SQL語句:analyze table xxx compute statistics for all indexes
E、爲何有時使用CBO會比較慢?
一、沒有對錶或視圖進行Analyze
二、SQL進行CBO時對於沒有Analyze的對象會自動進行Analyze,所以形成運行緩慢