執行計畫之誤區,為什麼COST很小,SQL卻跑得很慢?,執行計畫cost

來源:互聯網
上載者:User

執行計畫之誤區,為什麼COST很小,SQL卻跑得很慢?,執行計畫cost

轉載請註明出處:http://blog.csdn.net/guoyjoe/article/details/38321477

 

2014.7.31就晚20:30 My Oracle Support組貓大師線上分享
《執行計畫之誤區,為什麼COST很小,SQL卻跑得很慢?》
如需瞭解更多請登入網站http://www.jianfengedu.com/Discuz/detail/id/58

+++我給你看個東西。


--------------------------------------------------------------------------
| Id  | Operation   | Name | Rows  | Bytes | Cost (%CPU)| Time  |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |  |     1 |    10 |   349   (1)| 00:00:05 |
|*  1 |  TABLE ACCESS FULL| T1  |     1 |    10 |   349   (1)| 00:00:05 |
--------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   1 - filter("OBJECT_NAME"='00440')

table name:T1
column name:OBJECT_NAME
num_rows:87417
num distinct:48128
num_nulls:797
density:.0000115446779034865
histogram:HEIGHT BALANCED
high_value:4435(D5) -- internal value:354151154089362000000000000000000000
low_value:3030343432(00442) -- internal value:250207940888765000000000000000000000

00400 internal Value : 250207940886347000000000000000000000

ENDPOINT_VALUE      ENDPOINT_NUMBER BUCKET_COUNT
-------------------- --------------- ------------
46641      40  1
47796      41  1
A1      49  8
B2      58  9
C3      66  8
D5      75  9

 

Density = (Bucket_total - Buckets_all_popular_value)/
Bucket_total/(NDV - popular_values.COUNT)
 =(75 - 34)/75/(48128 - 4) = .00001136

Sel = .00001136 * (87417 - 797)/87417 * (1 - ((250207940888765000000000000000000000 - 250207940886347000000000000000000000)/

(354151154089362000000000000000000000 - 250207940888765000000000000000000000)))
= .000011256
Card = 87417 * .000011256 = .983965752

這是:col=val and val<low_value and value>2*low_value - high_value
類似這樣的條件的演算法。

high_value:4435(D5) -- internal value:354151154089362000000000000000000000
low_value:3030343432(00442) -- internal value:250207940888765000000000000000000000

00400 internal Value : 250207940886347000000000000000000000

這三個數字是怎麼得出來的?

D5在dba_tab_columns裡,存成這樣的:4435, 其實oracle內部計算用的值是:354151154089362000000000000000000000


 Density * A4Nulls * (1 - ((val - low_value)/(high_value - low_value)))這是公式, 有這個公式,是沒有用的。你不會用。

與其實, 他在告訴你怎麼COST,不如說,他是想告訴你, 怎麼研究oracle的演算法。

其實就是告訴你, 怎麼猜。 裡面也有錯的。

比如cardinality他都是用ceil()一下, 其實,oracle多數情況下用round

國內頂級SQL最佳化課程

8月5號啟動QTune系列I CBO內部演算法--老貓
http://item.taobao.com/item.htm?spm=a1z10.1.w4004-6565782199.6.1TCjTi&id=40189797849


DSI之系列I CBO內部演算法
--2014.8.5啟動(14課時,7天課)
¥499/每人


選擇率,基數計算公式
-------------------------
1. 單表無長條圖
 1.1 (col = val)在range內
 1.2. (> < <= >= between, 在range內
 1.3. out-of range
 
2. 單表有frequency長條圖
 2.1 (col = val)在range內
 2.2. (> < <= >= between, 在range內
 2.3. out-of range
 
3. 單表有hight balanced長條圖
 2.1 (col = val)在range內
 2.2. (> < <= >= between, 在range內
 2.3. out-of range
 
4. Join選擇率計算


成本計算公式:

1. 重要的概念 
----------------- 
 1.1
 1.2 Cost計算模型.
 1.3 Cost單位. 
 1.4 單塊讀的次數(#SRds)
 1.5 多塊讀的次數(#MRds)
 1.6 系統統計資訊
 1.7 Join Selectivity & Cardinality
 
2. 單表訪問(沒有長條圖) 
------------------ 
 2.1 Cost Model Components
 2.2 全表掃描的成本計算
 2.3 表的Cardinality和selectivity
 
3. Index掃描 
------------------ 
 3.1 公式:
 3.2 通過B*Tree index掃描表

Join
--------- 
4. Nested Loop

5. Hash Join and Sort Merge Join


重磅推出後繼課程
QTune系統II   transformaction.
QTune系統III   qtune案例實戰
QTune系統IV   各種豐富的調優工具

不要4999,只要¥499
邊學邊送,還贈送多年的心血SQ最佳化資料!!!


———————————————尖峰最近線上沙龍分享活動錄製的視頻
caibird2005分享主題《資料倉儲環境的表拆分、分區表、並行計算 》
連結: http://pan.baidu.com/s/1eVA14

Clojure大師分享主題《rac study from scratch 》
連結: http://pan.baidu.com/s/16FRIm

Jack分享主題《儲存的前世今生和未來----儲存的若干關鍵技術和虛擬化》
連結: http://pan.baidu.com/s/1eQrECQe

Dasight博士分享主題《大資料時代的技術發展和對IT人的挑戰》
連結: http://pan.baidu.com/s/1bnenDtd
連結: http://pan.baidu.com/s/1sj0fJ5r

guoyJoe分享主題《BBED彙報演出 : UPDATE恢複揭密》
連結: http://pan.baidu.com/s/1i3mlPC5

Dasight博士分享主題《漫談大資料》
連結: http://pan.baidu.com/s/1mgLrAuG
連結: http://pan.baidu.com/s/1c0hCsSS

杜興分享主題《MySQL 5.6版本特性介紹及如何從MySQL 5.5向MySQL 5.6》
連結: http://pan.baidu.com/s/1eQ5oQp8
東大博士Dasight分享主題《Hadoop與Nosql技術的適用性分析》
連結: http://pan.baidu.com/s/1mg9g3Za
貓大師線上分享《通過一個案例徹底讀懂10046 trace--位元組級深入破解》
連結: http://pan.baidu.com/s/1pJsfFWv
連結: http://pan.baidu.com/s/1GmLqu 

加入VIP即可免費獲得以上分享視頻,以及今後的分享都會給出,只要10元會員費,如下連結
http://item.taobao.com/item.htm?spm=a1z10.1.w4004-6565782199.2.ul78Pt&id=38629931035


【尖峰線上沙龍技術分享QQ交流群】  252296815
【尖峰線上沙龍技術YY頻道】10799487
創造良好的Oracle技術氛圍,精心分享各種Oracle學習資源,廣集圈內好友,
 定期開展公益YY課堂深入學習以及適當線下交流!

 


Oracle的cost值越大,是不是這SQL的執行計畫就越差?

理論上是 cost值越大,SQL的執行計畫就不好.

但是還有一個前提,就是你的表的分析資料要正確。
cost 值的計算,是根據資料庫表的統計資訊來計算的。
例如 你有一個 一百萬行的表 ABC。 在 A 列上面有一個索引。


SELECT SUM(B) FROM ABC WHERE A = 100
在資料庫沒有表/索引的 相關統計資訊的情況下, 這個 cost 確實是估計出來的一個大概的值。偏差可能 與這個表中的 A=100 的數量有多少相關。
比如 100萬條記錄裡面, A=100 的資料只有一條 / A=100 的資料只有 十萬條。 執行的時間可是差很多的。
但是如果表/索引 沒有被分析過, 資料庫對於
SELECT SUM(B) FROM ABC WHERE A = 100
還是
SELECT SUM(B) FROM ABC WHERE A = 1000
查詢的計劃,是一樣的。

但是如果你的 表/索引, 是已經分析過了的, 那麼 cost 所反映出來的值, 可能更精確一些。
因為在分析的時候,就能知道 A=100 的資料只有一條 還是有 十萬條。
資料庫可以根據需要,選擇最佳的查詢方案來進行處理。
假如 那一百萬條資料中, A=100 的資料只有一條 ,而 A=1000的資料,有 八十萬條。
那麼很可能
SELECT SUM(B) FROM ABC WHERE A = 100
使用索引的查詢計劃


SELECT SUM(B) FROM ABC WHERE A = 1000
使用全表掃描的查詢計劃。
 
【SQL執行計畫教】sql中只有這些地方cost值特別高,問原因在哪兒,怎更改善?執行計畫應該怎解讀?

是你最下面一個 的 cost 高(還沒有貼出來)

剩下的都是在 下面 的基礎上 加上 自己 的結果。

也就是說, 每個都是 本節點 及 其 下面所有節點 的 cost 和
 

相關文章

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.