SQL Server执行计划问题

我有两台服务器正在进行开发，我不是DBA，但我们没有一台，所以我试图找出一些性能问题。我在本地安装了SQLServer2008R2，当我使用的ORM运行查询时，它会在不到一秒钟内返回结果。当我使用is SQL server 2005在开发服务器上运行完全相同的查询时，需要花费一分钟的时间。我已经查看了它们的执行计划，最突出的是查询的最后两行有一条ORDERBY语句。在2005服务器上，这是成本的100%。在2008服务器上，这是成本的0%。有什么我可以俯瞰的场景吗？两台服务器中的数据大致相同，索引/密钥等也相同……因为本地副本只是从备份中恢复

我最好的猜测是2005服务器正在对所有表进行排序，然后给我结果（200行）。2008服务器将获取所有结果，然后对其进行排序。（还有200个结果。）

链接到慢速执行计划：

链接到快速执行计划：

我会发布这个查询，但它太长了，这让人讨厌，因为我有一堆生成查询的include及其实体框架

先谢谢你

编辑：我在正在运行的SQL server上打开了任务管理器，在执行此查询期间，CPU将达到100%

编辑：将XML版本添加到jsfiddle.net。因为尺寸太大，pastebin不允许我这么做。只是使用CSS窗口来显示XML

2008年实际情况R2：

---

---

2005年实际情况：

如果看不到查询，很难判断，但是否可能在速度较慢的服务器上缺少索引？

如果看不到查询，很难判断，但是否可能在速度较慢的服务器上缺少索引？

在开发服务器上，统计信息可能已过时

dev服务器上的统计信息可能已过期

排序200行不应该对这个时间差负责，因此估计的成本似乎相差很远。也许统计数据需要在2005服务器上更新。两个版本的计划中显示的成本只是基于这些统计数据的估算。计划中的估计行和实际行之间有任何差异吗？这些是实际的还是估计的执行计划？与@JNK一致-在我们看到一些细节之前，我们只能猜测。疯狂。如果不使用

orderby

，这两个查询返回的速度会更快吗？还是比例仍然相同？计划中是否有其他主要差异（例如，速度慢的服务器是否有额外的排序操作符）？@Aaron Bertrand-如果没有order by子句，速度慢的服务器执行速度会快得多。不到10秒。在fast服务器上，这显然是一个较小的改进，因为它已经相当快了。排序200行不应该对这个时间差负责，所以估计的成本似乎相差很远。也许统计数据需要在2005服务器上更新。两个版本的计划中显示的成本只是基于这些统计数据的估算。计划中的估计行和实际行之间有任何差异吗？这些是实际的还是估计的执行计划？与@JNK一致-在我们看到一些细节之前，我们只能猜测。疯狂。如果不使用

orderby

，这两个查询返回的速度会更快吗？还是比例仍然相同？计划中是否有其他主要差异（例如，速度慢的服务器是否有额外的排序操作符）？@Aaron Bertrand-如果没有order by子句，速度慢的服务器执行速度会快得多。不到10秒。在fast服务器上，这显然是较小的改进，因为它已经相当快了。这是可能的，但OP确实说了“相同的索引/键等”。。。我猜这是三件事之一——由于过时的统计数据、参数嗅探而导致的错误估计，或者由于运算符选择不当而导致的不必要的排序（这可能是由于上述原因之一）。但在猜测之前先看看实际计划会很好。啊，不知怎么的，我错过了，谢谢。在这种情况下，您列出的内容之一可能是它。这是可能的，但OP确实说了“相同的索引/键等”。。。我猜这是三件事之一——由于过时的统计数据、参数嗅探而导致的错误估计，或者由于运算符选择不当而导致的不必要的排序（这可能是由于上述原因之一）。但在猜测之前先看看实际计划会很好。啊，不知怎么的，我错过了，谢谢。在这种情况下，您列出的内容之一可能就是它。几个小时前，在我问了这个问题之后，我运行了“EXEC sp_updatestats”。它没有改变任何结果。我在几个小时前问完这个问题后立即运行了“EXEC sp_updatestats”。它没有改变任何结果。