執行計畫中cost計算方法,執行計畫cost
概念:
blevel:二元高度=索引高度-1
clustering_factor:叢集因子,掃描index scan得出的要掃描的表中block數,clustering_factor<=table blocks
索引掃描的計算公式:
cost =
blevel +
ceil(leaf_blocks *effective index selectivity) +
ceil(clustering_factor * effective table selectivity)
一下測試是在rule based optimizer used條件下
SQL> select leaf_blocks,blevel,clustering_factor from dba_indexes where index_name='IDX_T';LEAF_BLOCKS BLEVEL CLUSTERING_FACTOR----------- ---------- ----------------- 112 1 776
SELECT b.num_rows, a.num_distinct, a.num_nulls, utl_raw.cast_to_number(high_value) AS high_value, utl_raw.cast_to_number(low_value) AS low_value
, b.num_rows - a.num_nulls AS "NUM_ROWS-NUM_NULLS", utl_raw.cast_to_number(high_value) - utl_raw.cast_to_number(low_value) AS "HIGH_VALUE-LOW_VALUE"
FROM dba_tab_col_statistics a, dba_tables b
WHERE a.owner = b.owner
AND a.table_name = b.table_name
AND a.owner = 'SCOTT'
AND a.table_name = upper('TEST')
AND a.column_name = 'OBJECT_ID'
NUM_ROWS NUM_DISTINCT NUM_NULLSHIGH_VALUELOW_VALUENUM_ROWS-NUM_NULLSHIGH_VALUE-LOW_VALUE
50736 5073515382025073553818
effective index selectivity=(limit-low_value)/(high_value-low_value)
SQL> select (1000-2)/(53820-2) selectivity from dual;SELECTIVITY-----------0.018543982
SQL> SELECT OWNER FROM TEST WHERE OBJECT_ID<1000;已選擇953行。執行計畫----------------------------------------------------------Plan hash value: 1810195980---------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost |---------------------------------------------------------------------| 0 | SELECT STATEMENT | | 941 | 10351 | 19 || 1 | TABLE ACCESS BY INDEX ROWID| TEST | 941 | 10351 | 19 ||* 2 | INDEX RANGE SCAN | IDX_T | 941 | | 4 |---------------------------------------------------------------------Predicate Information (identified by operation id):--------------------------------------------------- 2 - access("OBJECT_ID"<1000)
1.回表io=ceil(clustering_factor * effective table selectivity)=19-4=15
2.blevel +ceil(leaf_blocks *effective index selectivity)
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
使用全表掃描的查詢計劃。
plsql 執行計畫 cost 什意思
Oracle給出的衡量執行計畫的單位
一般Cost越低 證明執行計畫越合理