根据我可以通过Google找到的任何文档,查询成本是一个百分比数字,并表示其中任何一部分占用的整批数量的百分比.
这对我来说似乎有点奇怪,因为我对特定查询的绝对优点感兴趣,而不是相对于碰巧与它一起出现的其他查询的优点.
但后来我想,好吧,也许你应该做的是并排放置两个替代查询,将它们作为“批处理”运行,然后以低于50％的成本为准.
但是在第6章,微软的sql 70-433培训套件第一课中对查询成本的讨论似乎与此没有任何关系.
下面是一个示例：它们显示包含两个相关子查询的查询,然后通过用OUTER APPLY替换子查询来改进它.结果是：“此查询的成本大约为76,而第一个查询的成本是大约151的两倍.”
然后,他们进一步改进查询,并将成本从76降低到3.6.它们并不意味着这些数字是百分比,而它们确实暗示它们是与查询作为独立对象相关的绝对数字,而不涉及任何其他查询.无论如何,第一个查询怎么可能有151％的成本？
在本章后面,他们展示了执行计划的屏幕截图,其中包含三个部分.第一个表示“成本：0％”,第二个表示“成本：1％”,最后一个表示“成本：99％”但文本(图书本身)位于屏幕截图“此查询的成本为0.56”之下.
我猜它们意味着其他一些成本,但我在其他地方找不到它的参考.
有人可以帮忙吗？我很困惑.
解决方法
但现在应该被解释为总体成本的无单位度量.
执行计划是一棵树.树中的每个迭代器都会获得估计的cpu成本和估计的IO成本,并将它们相加以获得总体成本(相对权重可以使用couple of undocumented DBCC commands进行调整).估计的子树成本包括迭代器本身及其所有后代的成本.要查看使用的成本计算公式的示例,您可以查看this article.
要确定SSMS中整个查询的估计开销,请选择图形计划左侧的根迭代器(例如SELECT迭代器),并在SSMS属性窗口中查看此度量标准.
当运行多个查询(无论是否在同一批次中)时,通过将所有这些值相加并按预期计算百分比来计算百分比.
您应该知道,即使在实际执行计划中,此成本数字也是基于估算值,并且使用它来比较两个不同查询的相对优点在估算值不准确的情况下可能是错误的.
