执行计划之误区，为什么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)))这是公式， 有这个公式，是没有用的。你不会用。
与其实， 他在告诉你怎么ＣＯＳＴ，不如说，他是想告诉你， 怎么研究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课堂深入学习以及适当线下交流!
理论上是 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
使用全表扫描的查询计划。
是你最下面一个 的 cost 高（还没有贴出来）
剩下的都是在 下面 的基础上 加上 自己 的结果。
也就是说， 每个都是 本节点 及 其 下面所有节点 的 cost 和