设为首页 收藏本站
查看: 651|回复: 0

[经验分享] SQL Server 2000执行计划成本(4/5)

[复制链接]

尚未签到

发表于 2016-11-5 09:24:28 | 显示全部楼层 |阅读模式
  
[转]SQL Server 2000执行计划成本(4/5)
循环、哈希与合并连接比较 

      在分别讨论了循环、哈希与合并连接的执行计划成本规则之后,现在将3个连接类型放到适合各自条件的环境下一起比较。 
下面的图2-27显示了循环、哈希与合并连接在1P/2P系统上的启动成本。外部源和内部源启动成本描述了索引搜索的基本成本包括每行成本0.0000011。连接成本也除去第一行,这样似乎仅有个案是少量变化的。4P系统的启动成本仅在索引搜索基本成本(0.003283025)上不同。

http://www.sql-server-performance.com/images/jc_sql51.gif 
图2-27.循环、哈希与合并连接在1P/2P系统上索引搜索的启动成本

      表2-1显示了在一对一的循环、哈希与合并连接在两个表都有明确的SARG下的每行成本和每页成本。每行(/r)成本适用于所有行,每页(/p)成本仅适用于需要增加的叶页。每行和每页总成本的规则需要将每页条件计算在内。
Per row costs 1-1
Outer Source
Inner Source
Join
Total
Loop0.00000110/r0.00007960-0.00000418/r0.000084880-
Hash+0.00074074/p~0.00015400/r~0.00001881/r~0.000155280
Merge0.00000110/r0.00000110/r~0.00000446/r+0.00074074/p

表2-1.连接里增加行的成本规则构成
 
      表2-2显示了每页10行和100行时计算得到的每行总成本,此时还要计算增加的叶页成本。
Per row costs 1-1
10 rows / page
100 rows / page
Loop0.00022940.0001627
Hash0.00016920.0000358
Merge0.00015480.0000215

 
表2-2.连接里增加行的成本规则构成

      循环连接的启动成本最低且确定。这主要是由于循环连接操作自身没有而哈希与合并连接各自有~0.017770与~0.0056046的基本成本。 
3个连接的外部源成本相同,都是索引搜索操作。3个连接类型在每行成本结构上的不同大部分来自内部源,部分来自连接自身。循环连接的内部源成本结构反映了重复的索引搜索操作。哈希与合并连接的内部源成本结构仅仅是索引搜索操作。连接自身的每行成本循环连接是最低的,紧随的是合并连接而哈希连接大约是循环连接的4倍。 
      少量行参与时循环连接的成本结构有最低的计划成本。合并连接有最低的总的每行成本,接着是哈希连接,而循环连接有最高每行成本。合并连接总是比哈希连接的计划成本低。在一些行参与时,合并连接的开销小于循环连接。在大类行参与时,哈希连接也比循环连接的开销低。合并与哈希连接的好处在于对于高密度(每页行数)索引来说每行成本是最好的。当每页里的行数即密度低时,内部源的每行成本抵消了合并与哈希连接的这一好处。 
表2-3显示了内部源增加行的每行成本。
 
Additional IS costs per rowInner SourceJoin
Loop0.00000110/r +0.00074074/p 
0.00000418/r
Hash0.00000110/r +0.00074074/p 
0.00000523/r 
Merge0.00000110/r +0.00074074/p0.00000237/r

表2-3增加行的内部源成本

      注意循环连接的每页组件仅适用于外部源每行连接到内部源足够多的行以要求额外的叶页的情形,而哈希与合并连接的每页组件适用于内部源的所有行的总和要求额外的叶页的情形。如果每个表的行数差别很大,那么哈希和合并连接就会丧失其好处,因为循环连接有更低的内部源每行成本。 
图2-28a和2-28b显示了循环、哈希与合并连接在为内部源和外部源表指定明确的搜索参数情形下1P/2P系统的正常的总成本,此时每个表有适当的索引,且外部源的每一行正好连接到内部源的一行。查询成本的计算和1P/2P系统的单行索引搜索成本(0.0064081)有关。

http://www.sql-server-performance.com/images/jc_sql41.gif 
图2-28a.1P/2P系统上的循环、哈希与合并连接的总成本(对数比例)

http://www.sql-server-performance.com/images/jc_sql42.gif 
图2-28b.1P/2P系统上的循环、哈希与合并连接的正常成本(线性比例)

      循环连接操作自身没有启动成本,仅在内部源和外部源表的索引搜索操作上有启动成本。哈希连接操作的启动成本在1P/2P系统上刚刚少于索引搜索的3倍而总的启动成本刚刚少于索引搜索操作的5倍。合并索引的启动成本在1P/2P系统上刚刚少于单个索引搜索而总的启动成本也稍微少于索引搜索的3倍。当两个表上有适当的的聚集索引或覆盖索引可用时,合并连接变得比循环连接在40行时有利,哈希连接则在~160行时比循环连接有利。在这个例子里,执行计划使用紧凑的高密度(每页超过400行)的覆盖索引。对于低密度的索引来说交叉点在更高的位置。 
      图2-29显示了4P系统的循环、哈希与合并连接的成本。4P系统的3个类型的连接的交叉点与1P/2P系统稍微有些不同。在4P服务器上,索引搜索基本I/O成本大约是1P/2P系统的一半。哈希与合并连接基本成本在1P/2P和4P系统上没有变化,所以启动成本在绝对数值上更低,但4P系统的索引搜索成本更高。

http://www.sql-server-performance.com/images/jc_sql43.gif 
图2-29.4P系统上的循环、哈希与合并连接的正常成本(线性比例)

      图2-30显示了带排序的合并和多对多合并连接和标准的循环、哈希、合并连接的比较。
http://www.sql-server-performance.com/images/jc_sql44.gif 
图2-30.带排序的合并和多对多合并连接与循环、哈希、合并连接的比较(都在4p系统上)

      带排序的开销在参与行不多时稍微少于哈希合并连接,但在参与行很多的时候开销就更高了。多对多合并连接在参与行不多时成本介于常规的合并和哈希连接之间,但在参与行很多的时候开销就要比两者都高。 
      在两个表中仅有一个存在搜索条件的情形下,哈希与合并连接会要求对另一个表进行表扫描。循环连接可以使用连接条件上的索引来避免表扫描。由于在1P/2P系统上表扫描基本成本是索引搜索基本成本的6倍(4P系统上是12倍),并且比增加的行成本高得多。所以合并与循环、哈希与循环的交叉点位于参与行充分多的时候(500-700行)。 
      当然,循环、哈希与合并连接的特征在BOL的“优化数据库性能”一节的“高级查询调优概念”里有描述。然而,看看实际的数字而不是依赖于定性的描述如小规模相似是值得的。
 
Tag标签: SQLServer2000

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-296016-1-1.html 上篇帖子: [转]SQL Server 2000执行计划成本(3/5) 下篇帖子: RAID在SQL Server中的应用(RAID几种级别)
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表