未加星标

SQL Server实际执行计划COST"欺骗"案例

字体大小 | |
[数据库(mssql) 所属分类 数据库(mssql) | 发布者 店小二04 | 时间 2018 | 作者 红领巾 ] 0人收藏点击收藏

有个系统,昨天Support人员发布了相关升级脚本后,今天发现系统中有个功能不能正常使用了,直接报超时了(Timeout expired)错误。定位到相关相关存储过程后,然后在优化分析的过程中,又遇到了执行计划COST “ 欺骗 ” 我们的这种情况,其实在我这篇博客 ” SQL SERVER中用户定义标量函数(scalar user defined function)的性能问题 “ 有提及这个问题,但是很多时候,我们优化SQL的时候,会习惯去查看实际执行计划COST所占的开销比例,从而判断性能开销最大SQL语句。当然大多数时候,这也是正确的。我们先来看看这个案例吧,如下所示,这个存储过程的部分实际执行计划如下(实际执行计划实在太长,无法全部展现):


SQL Server实际执行计划COST

我们将实际执行计划保存为sqlplan类型的文件(Execution Plan Files),然后用Plan Explorer展现出来,如下所示,Est Cost% 和 Est CPU Cost% 显示第一个SQL语句是整个存储过程里面开销消耗最大的SQL语句。然后去测试验证,发现这个SQL不是开销最大的SQL,也就是说执行计划欺骗了我们,实际上,下面Est Cost %为13.3的SQL才是性能开销最大的SQL


SQL Server实际执行计划COST
SQL Server实际执行计划COST

从实际执行计划中找到elapsed time最长的SQL 这个SQL才是真正影响性能的SQL语句,然后查看这个SQL,发现其查询条件(WHERE)使用了自定义标量函数(因为修改业务逻辑,查询条件添加了自定义函数过滤数据),然而这个从实际执行计划去看也是看不出问题的,因为这个自定义标量函数哪怕调用了几十万次,它的开销代价在实际执行计划中并没有呈现出来。具体原因截取 “ SQL SERVER中用户定义标量函数(scalar user defined function)的性能问题 “ 中的一段翻译如下:

翻译:

但是需要再次注意,执行计划在欺骗你,首先,它意味着只调用了UDF一次,其实不是这样。其次,从成本(Cost)来看,你可能会认为0%是向下舍入影响,因为单次执行函数的开销如此之小,以至于执行100,000次的成本也很小。但如果你检查执行计划的功能迭代器的属性,你会发现所有的操作代价和子树代价实际的估计为0,这是一个最糟糕的谎言。因为它可能不只是为了欺骗我们,而是SQL SERVER为了欺骗它自己。实际上是查询优化器认为调用函数的成本为0,因此它生成的所有执行计划都是基于调用UDF是免费的。其结果是即使调用标量UDF的代价非常昂贵,查询优化器也不会考虑优化它。

其实又单独总结一下这个问题,是因为人们或多或少受习惯性思维的影响,哪怕我之前多次遇到这种案例,但是在调优过程中,我还是会习惯性按照实际执行计划的COST比例去定位性能开销大的SQL语句,直到我通过验证推翻了这个判断,然后通过elapsed time最长的SQL语句才定位到开销最大的SQL。所以在调优、优化过程中,一定要多方位着手,反复推敲验证,不能被经验主义牵着鼻子走!

本文数据库(mssql)相关术语:熊片数据库 mssql数据库 oracle数据库 pubmed数据库 access数据库 万方数据库

tags: SQL,执行,开销,计划,Cost,COST,标量,函数,欺骗,调用,UDF,Est,SERVER
分页:12
转载请注明
本文标题:SQL Server实际执行计划COST"欺骗"案例
本站链接:https://www.codesec.net/view/604956.html


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 数据库(mssql) | 评论(0) | 阅读(9)