【问题标题】:How to read the hints in SQL Server Management Studio execution plan如何阅读 SQL Server Management Studio 执行计划中的提示
【发布时间】:2012-08-28 22:59:18
【问题描述】:

我很难理解您可以通过 SQL Server Management Studio 获得的执行计划中的提示。这是一个示例(简化,但包含所有内容)

索引搜索(非集群)

谓词

PROBE([Bitmap1047], ScheduleId)

对象

IX_Date

输出列表

ScheduleId 日期

寻找谓词

日期>=‘2012-01-02’日期

  • ScheduleId 是一个基于 guid 的外键。
  • IX_Date 是一个包含 Date、ScheduleId 和 INCLUDE Hours 的索引

对我来说,上面看起来很不错。 Index Seek 应该不错。它达到了相关指数。但是,此项目占用了很大一部分执行时间(否则我不会费心去理解它)。这让我感到困惑,我怀疑这是因为在阅读本文时有一些基本的东西我不明白。

谁能帮我解释一下?

【问题讨论】:

  • Index Seek 返回的“实际行数”和“估计行大小”是多少?
  • 我更新了问题以包含此信息。
  • 你能发布完整的查询计划吗?
  • 嗨,贾斯汀,谢谢,但恐怕我已经没有直接可用的查询计划了,那是很久以前的事了。但问题也更多是关于如何阅读而不是分析具体问题。
  • 这里,只有查询的日期部分可以用于索引查找,PROBE(...) 条件应用于匹配日期部分的所有行。请参阅blogs.msdn.com/b/craigfr/archive/2006/07/07/652668.aspx 以获取有关多列索引中列顺序的好文章以获得良好的提示。在这里可能不可用,因为我不知道 PROBE-Statement 是否是相等比较。

标签: sql-server-2008 indexing ssms sql-execution-plan


【解决方案1】:

根据您提供的数据,我没有看到任何看起来太奇怪的地方。在这个计划中,非聚集索引查找的成本只有 12%,所以除非有很多其他操作需要花费很短的时间并且这个操作相对较大,否则我觉得还可以。

我认为执行成本可能看起来很高,因为它正在对 50 万行进行非聚集索引查找。

【讨论】:

  • 这个操作有 5 次,每次占用 12%,所以这就是为什么我把它看作是罪魁祸首。我可以阻止它在具有某种索引的那么多行中进行索引搜索吗?
  • 这听起来确实是个问题。如果在这五种情况中的每一种中查找都相同,则您可能会以不同的方式编写查询,因此仅执行一次查找。是否可以发布查询本身?
  • 查询是从实体框架自动生成的。我知道我可以重写查询,但我不能轻易做到这一点,这就是为什么我用这张票,试图专注于阅读执行计划,并根据我已有的内容进行优化。
  • 我明白了。可以使用稍微不同的 Linq 查询来使用更好的执行计划生成相同的数据。您还可以稍微改变您的实体和关系以生成更好的查询。最后一种选择是将查询放在存储过程中,但这违背了实体框架的目的。
  • 您使用的是 EF4 还是更新版本?您可以尝试升级到最新版本,看看它是否会为您的实体生成更好的 SQL 代码。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多